|
Разработка алгоритмов и программных средств подсистемы документооборота системы управления содержанием информационного сервера2. Интерфейс между средствами разработки сообщений и системой документооборота и обработки сообщений. Определяет способы взаимодействия средств разработки сообщений, с одной стороны, и системы документооборота - с другой. Передаются проекты документов и копии документов, имеющие статус электронных сообщений, а также сопровождающие их комментарии, замечания и т.д. 3. Интерфейс между информационной системой и системой документооборота. Сообщения формируются в информационной системе при помощи генераторов отчетов и передаются в систему документооборота. Этот интерфейс имеет смысл и в том случае, если рассматривать систему документооборота как составную часть корпоративной информационной системы. Рассмотрим некоторые основные принципы и правила автоматизированного документооборота. Система автоматизированного документооборота должна прежде всего осуществлять эффективную обработку и перемещение электронных документов, создавая тем самым физическую среду для информации. При разработке или выборе технологии обработки документов и управления документопотоками необходимо учитывать ограничения технического характера, связанные: . с соблюдением стандартов; . с защитой электронного документа и его реквизитов; . с обработкой информации в графическом виде. Международными организациями по стандартизации (ISO, CCIT, ЕСМА) проводится большая работа по унификации электронных документов. В работах по созданию этих стандартов решаются не только технические проблемы согласования различных структурных характеристик документов. Главное заключается в том, что разрабатывается общая модель документа, которая является основой выработки нескольких взаимоувязанных стандартов. Проблема защиты электронного документа и его реквизитов определяется требованием неизменяемости документа после придания ему юридической силы. Содержимое файла документа и его реквизиты могут быть защищены от несанкционированного изменения путем разработки специальной структуры файла и включения в его состав средств электронной подписи. Такой способ защиты должен быть надлежащим образом сертифицирован, законодательно регламентирован и признан всеми участниками документооборота. Проблема обработки информации в графическом виде возникает в отношении сканированных образов документов, поскольку выходная информация сканера создается в виде графического файла. Текст в графическом файле не может быть обработан типовыми средствами такими, как текстовые процессоры или СУБД. Кроме того, графические файлы имеют большие размеры. В настоящее время существуют компьютерные системы, позволяющие обрабатывать большие объемы графической информации за приемлемое время, однако из-за высоких требований к их характеристикам стоимость таких систем достаточно высока. С позиций повышения эффективности и снижения ресурсоемкости сегодня наибольший интерес представляет решение оптимизационных задач, которые существенно сдерживают процесс перехода управления документооборотом на качественно новый уровень. Оптимизационный характер ряда задач построения систем документооборота вытекает из основных технологических требований к документообороту. [3] Таблица 1 Требования, предъявляемые к документообороту |Прохождение /документов кратчайшим путем | |Избирательность распределения документов между руководителями и | |специалистами | |Обусловленность перемещения документов деловой необходимостью | |Единообразие маршрута движения и состава технологических операций для| |массовых категорий документов | |Однократность выполнения каждой операции | 1.4. Средства создания информационных серверов PHP — это серверный (или серверной стороны) язык сценариев, разработанный специально для Web. В HTML-страницу можно внедрить PHP-код, который будет выполняться при каждом ее посещении. PHP-код интерпретируется Web-сервером и генерирует HTML-код или другой вывод, наблюдаемый посетителями страницы. Разработка РНР была начата в 1994 году и вначале осуществлялась одним человеком, Расмусом Лердорфом (Rasmus Lerdorf). Этот язык был принят рядом талантливых людей и претерпел три основных редакции, пока не стал широко используемым и зрелым продуктом, с которым мы имеем дело в настоящее время. По состоянию на октябрь 2002 года он использовался в более чем девяти миллионах доменов разбросанных по всему миру, причем их число неуклонно растет. Текущее юличество доменов, в которых используется РНР, можно посмотреть по адресу http://www.php.net/usage.php. PHP - это продукт с открытым исходным кодом, то есть вы имеете доступ к исходному коду. Его можно использовать, изменять и свободно распространять другим пользователям или организациям. Первоначально РНР являлось сокращением от «Personal Home Page» («Персональная домашняя страница»), но затем это название было изменено в соответствии с соглашением по рекурсивному именованию GNU (GNU = Gnu's Not Unix) и теперь означает «РНР Hypertext Preprocessor» («Гипертекстовый препроцессор РНР»). В настоящее время основной версией РНР является четвертая. Адрес домашней страницы РНР выглядит как http //www.php.net. MySQL - очень быстрая, надежная система управления реляционными базами данных (СУРБД). Вообще говоря, база данных позволяет эффективно хранить, искать, сортировать и получать данные. Сервер MySQL управляет доступом к данным, позволяя работать с ними одновременно нескольким пользователям, обеспечивает быстрый доступ к данным и гарантирует предоставление доступа только пользователям, имеющим на это право. Следовательно, MySQL является многопользовательским, многопоточным сервером. Он применяет SQL (Structured Query Language - язык структурированных запросов), используемый по всему миру стандартный язык запросов в базы данных. MySQL появился на рынке в 1996 году, но его разработка началась еще в 1979 году. В настоящее время пакет MySQL доступен в соответствии с лицензией Open Source, но в случае необходимости можно получить и коммерческие лицензии. Приступая к созданию информационного сайта, можно использовать множество различных продуктов. Возникает необходимость в выборе следующих компонентов: . оборудование для Web-сервера; . операционная система; . программное обеспечение Web-сервера; . система управления базами данных; . язык программирования или создания сценариев. Выбор некоторых из этих компонентов будет зависеть от уже произведенных выборов. Например, не все операционные системы могут работать на любом оборудовании, не все языки создания сценариев могут обеспечить подключение ко всем базам данных и т. д. Одно из замечательных свойств РНР состоит в том, что он доступен для операционной системы Microsoft Windows, для многих версий UNIX и выполняется на любых полнофункциональных Web-серверах. Система MySQL обладает такой же степенью гибкости. В число конкурентов РНР входят Perl, Active Server Pages (ASP) от Microsoft, Java Server Pages (JSP) и Allaire ColdFusion. PHP обладает множеством преимуществ по сравнению с этими продуктами которых наиболее значительными являются: . высокая производительность; . наличие интерфейсов ко многим различным системам баз данных; . встроенные библиотеки для выполнения многих общих задач, связанных с Web; . низкая стоимость; . простота изучения и использования; . переносимость; . доступность исходного кода. Система РНР исключительно эффективна. Используя единственный недорогой сервер, можно обслуживать миллионы обращений в день. Результаты тестирования, опубликованные компанией Zend Technologies на своем официальном сайте http://www.zend.com, подтверждают более высокую производительность РНР по сравнению с конкурирующими продуктами. РНР обладает встроенной возможностью подключения ко многим системам управления базами данных. В дополнение к MySQL, помимо прочих, можно непосредственно подключаться к базам данных PostgreSQL, mSQL, Oracle, dbm, Hyperware, Informix, InterBase и Sybase. Используя стандарт открытого интерфейса связи с базами данных (Open Database Connectivity Standard— ODBC), можно подключаться к любой базе данных, для которой существует ODBC-драйвер. Это распространяется на продукты Microsoft и множества других компаний. Поскольку РНР был разработан для использования в Web, он имеет множество встроенных функций для выполнения большого разнообразия полезных задач, связанных с Web. С его помощью можно на лету генерировать GIF- изображения, подключаться к другим сетевым службам, отправлять сообщения электронной почты, работать с cookie-наборами и генерировать PDF-документы — и все это при помощи всего нескольких строк кода. Пакет РНР является бесплатным. Наиболее новую версию можно в любой момент, причем совершенно бесплатно, выгрузить из сайта по адресу http://www.php.net. Синтаксис РНР основан на других языках программирования, в первую очередь С и Perl. Пакет PHP можно использовать под управлением множества различных операционных систем. PHP-код можно разрабатывать в среде таких бесплатных Unix-подобных операционных систем, как Linux и FreeBSD, коммерческих версий Unix типа Solaris и IRIX или различных версий Microsoft Windows. Как правило, программы будут работать без каких-либо изменений в различных средах, в которых установлен пакет РНР. Пользователь имеет доступ к исходному коду РНР. В отличие от коммерческих закрытых программных продуктов, если нужно что-либо изменить или добавить в этом языке, то это всегда можно сделать. Не следует дожидаться, пока компания-изготовитель выпустит пакет исправлений. Нет необходимости беспокоиться о том, что изготовитель покинет рынок или перестанет поддерживать продукт. К конкурентам MySQL, помимо прочих, относятся PostgreSQL, Microsoft SQL Server и Oracle. MySQL обладает многими преимуществами, в том числе высокой производительностью, низкой стоимостью, простотой конфигурирования и изучения, переносимостью и доступностью исходного кода. MySQL, вне всяких сомнений, работает исключительно быстро. Результаты сравнительных тестов производительности, выполненных компанией- изготовителем, можно посмотреть на странице по адресу http://web.raysql.com/benchmark.html. Многие из этих сравнительных тестов показывают, что MySQL работает на порядок быстрее конкурирующих продуктов. Пакет MySQL доступен бесплатно в соответствии с лицензией на программное обеспечение с открытым исходным кодом или, если это необходимо для приложения, за небольшую сумму можно приобрести коммерческую лицензию. В большинстве современных баз данных используется язык SQL. Если ранее вы работали с другими СУРБД, переход к этой системе не должен вызывать какие-либо затруднения. Установка MySQL столь же проста, как и установка многих аналогичных продуктов. MySQL может использоваться в среде многих UNIX-подобных систем, а также в среде Microsoft Windows. Как и в случае РНР, исходный код MySQL можно свободно выгружать и изменять. [1] Глава 2. Подсистема организации документооборота «InfoBeacon» 2.1. Архитектура и функциональность подсистемы Давайте предположим, что в группу Web-разработчиков онлайн-издания некоторой компании входят хороший администратор-оформитель, редакторы тематических разделов и авторы статей. Сайт содержит регулярно обновляемые страницы новостей со всего мира, новостей и обзоров из сферы высоких технологий, спортивной и музыкальной рубрик. Главная страница отображает заголовки новейших статей по каждой из четырех категорий. В этом онлайн-издании администратор-оформитель обеспечивает привлекательный вид содержимого, а также контролирует содержание материалов и безопасность системы в целом. С другой, стороны авторы пишут замечательные статьи, но не умеют толком оформлять свои работы для представления в Web. Задача состоит в том, чтобы позволить каждому сконцентрироваться на своей работе и объединить результаты усилий, чтобы получилась оперативная служба новостей. Основные требования, которые будут предъявляться к этой системе: . увеличение продуктивности работы, позволив авторам сконцентрироваться на статьях, а дизайнеру - на оформлении; . позволить редактору просматривать статьи и выбирать те, которые будут публиковаться; . создать единообразный внешний вид сайта с использованием шаблонов страниц; . предоставить авторам доступ только к предназначенным для них областям сайта; . предотвратить изменение актуального содержимого. Первым делом, необходимо продумать способ ввода содержимого в систему. Для этого существует три возможности. 1. FTP Авторам и дизайнерам можно предоставить FTP-доступ к областям Web- сервера. Это позволит им загружать на сервер файлы со своих локальных компьютеров. Для загружаемых файлов потребуется выработать строгий стандарт именования (который позволит четко идентифицировать принадлежность изображений к тем или иным статьям). С другой стороны, можно воспользоваться основанной на Web системой, которая будет решать упомянутые задачи отдельно от загрузки файлов через FTP. Использование FTP порождает проблему, связанную с выдачей полномочий. Необходимая степень гибкости не дает возможность применять FTP-протокол для предоставления пользователям функциональности по передаче файлов. 2. Метод загрузки файлов HTTP-протокол предоставляет метод загрузки файлов при помощи Web- браузера. Язык РНР позволяет решать эту задачу очень просто и эффективно. Кроме того, метод загрузки файлов дает возможность хранить текст в базе данных вместо файлов. Для этого выполняется чтение во временный файл и сохранение его содержимого в базе данных, а не копирование в другую область файловой системы. 3. Интерактивное редактирование Пользователи должны иметь возможность, создавать и редактировать документы без задействования FTP-протокола либо другого метода загрузки файлов. Вместо этого авторам, например, можно предоставить большое текстовое поле, в котором они смогут редактировать содержимое своих статей. Несмотря на относительную простоту этого метода, он зачастую оказывается весьма эффективным. Web-браузер не предоставляет каких-либо возможностей по редактированию текста, кроме лишь функций копирования и вставки, за реализацию которых отвечает операционная система. Однако, когда требуется внести лишь небольшие изменения, скажем, исправить орфографическую ошибку, при помощи подобных функций подобное осуществляется достаточно быстро. [1] Как и при методе загрузки файлов, данные формы можно записать в файл либо сохранить в базе данных. В нашем проекте реализуется как раз последний метод ввода содержимого в систему. Итак, после того, как статья введена, ее можно отправить на редактирование. Для этого выбирается тематика статьи (в нашей системе это новости, компьютеры, спорт и музыка) и после этого материал отсылается соответствующему редактору. При входе редактора в систему у него появляется список статей, предназначенных для редактирования. Он может начать редактирование, написать сообщение автору статьи либо написать свою статью. При написании статью в чужой раздел у него будут права обычного автора на эту статью. Кстати, статью может редактировать и автор, пока редактор не нажмет ссылку «Готово». После нажатия этой ссылки статья становится недоступной ни для редактора, ни для автора. Она переходит в распоряжение администратора. Он может ее редактировать, удалить либо, что наиболее вероятно, опубликовать ее на сайте. Из рис.3 видно, что на протяжении своего маршрута документ попадает к трем участника процесса документооборота. То есть весь процесс обработки документа можно условно разделить на три этапа: создание, редактирование и публикация. Однако это разделение, как и названия этапов, достаточно условны потому, что границы между этими этапами не такие конкретные, как может показаться с первого взгляда. Например, администратор имеет доступ к документу еще на этапе редактирования. Он может следить за ходом редактирования, а также имеет право сам править или даже удалить документ. На схеме это никак не указано, так как в общем-то это дополнительная функция системы и принципиально ничего не изменяет в архитектуре системы. Она только дает больше прав администратору. Рис. 3. Маршруты документов в системе На рис. 4 показано, как эта подсистема маршрутизации документа вписывается в общую логическую структуру информационного сервера. Рис. 4. Описание логической структуры информационного сервера 2.2. Организация политики безопасности в рамках подсистемы При успешной аутентификации пользователя (сравнение данных, введенных пользователем для входа, с данными, введенными при регистрации, которые хранятся в базе данных), выводится список собственных статей, их состояние на данный момент, новые статьи для редактирования (если вошедший пользователь является редактором) и личные сообщения. Если пользователь еще не вводил данные для входа в систему, то отображается только форма входной регистрации. После входа автора в систему переменной сеанса auth_user присваивается значение. Информация, введенная в форме входной регистрации, передается в сценарий login.php, который сравнивает имя пользователя и пароль с соответствующим значениями базы данных. В случае успешного входа пользователь перемещается на страницу, на которой он пребывал ранее, с помощью значения глобальной переменной HTTP_REFERER. Это означает, что сценарий, входа в систему может вызываться из любой страницы приложения. Затем автор приветствуется с использованием его имени и ему предоставляете возможность выхода из системы. Эта ссылка всегда отображается в верхней част страницы stories.php, что позволяет легко выйти из системы в любой момент. Сценарий logout. php просто сбрасывает значение переменной auth_user. [1] При попытке передачи сценарию редактирования идентификатора статьи для изменения, этот же сценарий проверяет наличие прав доступа к этой статье, формируя запрос к базе данных с использованием имени пользователя вошедшего автора или редактора. Это позволяет надежно разграничить права доступа как между авторами, так и между редакторами. 2.3. Компоненты подсистемы и схема хранения данных В качестве статьи будем рассматривать документ состоящий из заголовка, текста и изображения. Такого рода документы вполне можно считать структурированными. Чем выше степень структуризации документа, тем проще его разбить на составляющие, которые будут храниться в базе данных. Преимущество такого подхода состоит в возможности единообразного структурированного представления всех документов. В качестве примера возьмем статью новостей. Заголовок будет храниться в своем поле отдельно от текста. Изображение, по самой своей природе, является отдельным компонентом документа. Поскольку заголовок является отдельным элементом, для его отображения можно задать стандартный шрифт и стиль, а также легко отделить заголовок от остальной части статьи, сформировав главную страницу заголовков. Другой подход применительно к крупным документам предполагает организацию отдельных абзацев в соответствие с отношением "один ко многим". Другими словами, каждый абзац будет храниться в отдельной строке базы данных и иметь связь с идентификатором главного документа. Такой вид динамической структуры документа позволит формировать страницу содержания для каждого документа и отображать каждый раздел независимо либо же отображать документ целиком. На начальном этапе необходимо принять чрезвычайно важное решение относительно метода хранения содержимого после его загрузки в систему. Поскольку вместе с текстом хранятся и метаданные, благоразумно поместить текстовую часть содержимого в базу данных. Несмотря на то что система MySQL способна хранить мультимедиа-данные все же лучше держать загружаемые изображения в файловой системе. Использование больших двоичных объектов (BLOB) в базе данных MySQL может привести к снижию производительности приложения. В базе данных будут храниться лишь имена файлов изображений. Дескриптор стандартным образом. Когда объем данных велик, очень важно оптимизировать их хранение. Подобно тому, как эффективность базы данных зависит от правильно выбранной индексации, файловая тема существенно выигрывает от хорошо продуманной системы каталогов. [1] В нашем проекте сайта новостей страницы отображаются в простом, тем не менее, структурированном формате. Каждая страница содержит набор статей, сформированных одним и тем же образом. Прежде всего, заголовок выводится крупным шрифтом, слева внизу отображается фотография, а справа – собственно заголовок статьи. Страница целиком содержится в стандартном шаблоне страниц, что является предпосылкой непротиворечивого оформления сайта. Подобный вид компоновки исключительно популярен. Какая бы ни отображалась страница, сначала выводите заголовок, затем текст и, наконец, нижний колонтитул. Реализация сайта с шаблонами заголовка и нижнего колонтитула позволяет легко и просто изменять оформление сайта, внося требуемые модификации только в файлы шаблонов. Возможно, авторы будут дополнять статьи фотографиями, которые они сделали самостоятельно. Нам необходимо достигнуть единообразия оформления, но что произойдет, когда какой-то автор загрузит крупное изображение высокого качества, а другой автор - небольшую картинку качества пиктограммы? Базируясь на предположении, что изображения, в основном, представляют собой фотографии, можно ограничиться лишь форматом JPEG и для манипулирования графикой воспользоваться соответствующими PHP-функциями. В нашем проекте существует довольно простой сценарий resize_image.php, который на лету изменяет размер изображения, в результате чего оно может выводиться с использованием дескриптора сценарий принимает три параметра, в число которых входит имя файла изображения, максимальная ширина и высота в точках. Не стоит полагать, что если указан максимальный размер 200 х 200, то изображение будет масштабировано в соответствии с этими значениями. Наоборот, масштаб изображения будет пропорционально уменьшен таким образом, чтобы заданные максимальные размерыне превышались. Например, изображение размером 400 х 300 будет уменьшено до размера 200x150. В результате максимально точно сохраняются пропорции изображения. Динамическое (то есть, на лету) изменение размеров изображения на сервере гораздо предпочтительнее, нежели простое задание атрибутов HEIGHT и WIDTH в дескрипторе разрешением может составить несколько мегабайт. Если же картинку уменьшить до приемлемых размеров, то размер может оказаться менее 100 Кб. Следовательно, нет надобности загружать на сервер файл большого размера, а затем предлагать браузеру изменить размеры изображения. Ключевой аспект операции изменения размеров состоит в вычислении новых параметров ширины и высоты. При этом определяется соотношение между реальными и максимальными размерами. Параметры $max_width и $max_height можно передать в одной строке запроса, в противном случае будут задействованы стандартные значения, определенные вначале сценария. Если изображение уже меньше заданных размеров, его ширина и высота остаются неизменными. Для хранения данных, необходимых для работы системы используется 6 таблиц: keywords, messages, pages, stories, writer_permissions, writers. Keywords служит для хранения ключевых слов для каждой статьи, что позволяет более эффективно найти статью с помощью функции поиска. Таблица 2. Структура таблицы keywords базы данных | Поле |Тип | |story |int(11) | |keyword |varchar(32)| |weight |int(11) | Поле story – это индивидуальный номер статьи, по которому она однозначно определяется, keyword – ключевое слово, weight – вес (цена) слова (изменяется от 1 до 10). Чем больше вес слова, тем больше релевантность этой статьи к запросу поиска. Во втором столбце указан тип данных для каждого поля, а в скобках максимальная длина значения поля. Таблица messages применяется для хранения сообщений, которыми могут обмениваться пользователи системы. Таблица 3. Структура таблицы messages базы данных | Поле |Тип | |message_id |int(11) | |from_user |varchar(32)| |to_user |varchar(16)| |body |text | |read |char(1) | |date |int(11) | Единственное, что хотелось бы отметить в этой таблице – это наличие поля read, которое может принимать значения 1 либо 0. При создании сообщения этому поля присваивается значение 0, а после того, как тот пользователь, которому оно адресовано, открывает страницу с сообщениями ему присваивается 1. Это служит для того, чтобы как-то выделить новые непрочитанные сообщения. В таблице pages есть всего 2 поля: это название раздела и краткое его описание. А вот таблица stories наиболее крупная из всех – она служит собственно для хранения статей и является основой всей системы. Таблица 4. Структура таблицы stories базы данных | Поле |Тип | |id |int(11) | |writer |varchar(16)| |page |varchar(16)| |headline |text | |story_text |text | |picture |text | |created |int(11) | |modified |int(11) | |published |int(11) | |for_admin |char(1) | Итак, поле id – индивидуальный номер статьи, writer – автор статьи, page – к какому тематическому разделу относится данная статья, headline – заголовок, story_text – основной текст, picture – адрес файла с изображением. Следующие 3 поля предназначены для работы с датой, соответственно создания, редактирования и публикации документа. Последнее поле по своей функциональности похоже на поле read из таблицы messages: оно может принимать 0 или 1. Поле принимает значение 1, когда редактор раздела нажимает ссылку «Готово», которое служит для отправки статьи администратору. То есть, когда в этом поле стоит 1, то уже не автор, не редактор не имею доступа к этому документу – он уже предназначен для проверки администратором. Таблица writer_permissions служит для присвоения редакторам прав управления тем или иным разделам. Кстати, редакторы определяются в последней таблице writers последним полем editor. Таблица 5. Структура таблицы writers базы данных | Поле |Тип | |username |varchar(16)| |password |varchar(16)| |full_name |text | |editor |char(1) | Подчеркнутые поля в приведенных таблицах означают, что данное поле является индексом всей таблицы. Заключение Итак, в своей курсовой работе я постарался собрать воедино наиболее важную и актуальную информацию по разработке информационных систем вообще и подсистему документооборота в частности. Были исследованы и проанализированы основные принципы создания ИС, ее структура и функциональность, взаимодействие основных компонентов. Также были рассмотрены новейшие и наиболее перспективные Web- технологии, которые уже сегодня с успехом использует при создании и обслуживании информационных серверов, содержащих в себе гигантские объемы информации. Была разработана, создана и протестирована собственная подсистема документооборота, в которой реализовались основные принципы построения и взаимодействия ИС, а также основная функциональность работы. Список литературы 1. Веллинг Л., Томасон Л. Разработка Web-приложений с помощью PHP и MySQL – М.: Издательский дом «Вильямс», – 2003. – 800с.: ил. 2. Гилмор В. PHP 4. Учебный курс – СПб.: «Питер», – 2001. – 352с.: ил. 3. Курбацкий А. Н. Автоматизация обработки документов - Мн.: БГУ, 1999. - 221с.: ил. Приложение 1. Листинги SQL-запросов по созданию таблиц Листинг 1. SQL-запрос создания таблиц базы данных # БД : `content` # # -------------------------------------------------------- # # Структура таблицы `keywords` # CREATE TABLE `keywords` ( `story` int(11) NOT NULL default '0', `keyword` varchar(32) NOT NULL default '', `weight` int(11) NOT NULL default '0' ) TYPE=MyISAM; # -------------------------------------------------------- # # Структура таблицы `messages` # CREATE TABLE `messages` ( `message_id` int(11) NOT NULL auto_increment, `from_user` varchar(16) NOT NULL default '', `to_user` varchar(16) NOT NULL default '', `body` text, `read` char(1) NOT NULL default '0', `date` int(11) default NULL, PRIMARY KEY (`message_id`) ) TYPE=MyISAM AUTO_INCREMENT=20 ; # -------------------------------------------------------- # # Структура таблицы `pages` # CREATE TABLE `pages` ( `code` varchar(16) NOT NULL default '', `description` text, PRIMARY KEY (`code`) ) TYPE=MyISAM; # -------------------------------------------------------- # # Структура таблицы `stories` # CREATE TABLE `stories` ( `id` int(11) NOT NULL auto_increment, `writer` varchar(16) NOT NULL default '', `page` varchar(16) NOT NULL default '', `headline` text, `story_text` text, `picture` text, `created` int(11) default NULL, `modified` int(11) default NULL, `published` int(11) default NULL, `for_admin` char(1) NOT NULL default '0', PRIMARY KEY (`id`) ) TYPE=MyISAM AUTO_INCREMENT=65 ; # # Структура таблицы `writer_permissions` # CREATE TABLE `writer_permissions` ( `writer` varchar(16) NOT NULL default '', `page` varchar(16) NOT NULL default '' ) TYPE=MyISAM; # -------------------------------------------------------- # # Структура таблицы `writers` # CREATE TABLE `writers` ( `username` varchar(16) NOT NULL default '', `password` varchar(16) NOT NULL default '', `full_name` text, `editor` char(1) NOT NULL default '0', PRIMARY KEY (`username`) ) TYPE=MyISAM; Приложение 2. Листинги основных PHP скриптов Листинг 2. Файл stories.php (основной файл системы)
Поменять пароль)'; print ' '; print ' (Выход)'; print ' '; $sql = 'select * from stories where writer = \''. $HTTP_SESSION_VARS['auth_user'].'\' order by created desc'; $result = mysql_query($sql, $conn); print 'Ваши статьи: '; print mysql_num_rows($result); print ' (Добавить)'; print ' '; if (mysql_num_rows($result)) { print '
} print (' // ************** // Меню редактора $conn = db_connect(); $sql = 'select * from writers where username = \''. $HTTP_SESSION_VARS['auth_user'].'\' '; $result = mysql_query($sql, $conn); $qry = mysql_fetch_array($result); if ($qry['editor']) { editor_menu ($HTTP_SESSION_VARS['auth_user']); } // ************** // Меню сообщений $conn = db_connect(); $sql = 'SELECT * FROM messages WHERE to_user = \''. $HTTP_SESSION_VARS['auth_user'].'\' order by date desc '; $result = mysql_query($sql, $conn); $num_results = mysql_num_rows($result); if ($qry) { if ($num_results) { print (' print '
} } } include('footer.php'); ?> ----------------------- Программа-браузер Сервер базы данных Система управления базами данных Программа-браузер Сервер приложений (СУБД) Сервер базы данных Сервер базы данных База данных (хранение) 1 Автор статьи (создание) 2 Редактор раздела (редактирование) 3 Администратор сайта (публикация) Сервер БД Transaction (Транзакция) Сервер приложений Web-сервер Пользователь Query Query (Запрос) Подсистема маршрутизации документов Подсистема типизации документов Схемы отображения документов Редактирование документа Взаимная переадресация Обмен сообщениями Обмен сообщениями Транзакция Запрос Страницы: 1, 2 |
|
