Описание модели предметной области средствами системы 1с это
Основы и этапы проектирования прикладных решений на заданной платформе, управленческая характеристика предметной области конфигурирования. Проектирование системы учета хозяйственных операций. Разработка дополнительных алгоритмов обработки информации.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 25.02.2016 |
Размер файла | 3,6 M |
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Курсовая работа
Разработка предметно-ориентированной конфигурации «Управленческий учет в ИТ-компании» на платформе «1С: Предприятие 8.3»
Введение
прикладной алгоритм учет
Информационные технологии - процесс, использующий совокупность методов и средств реализации операций сбора, регистрации, передачи, накопления и обработки информации на базе программно-аппаратного обеспечения для решения управленческих задач экономического объекта.
Развитие информационных технологий, как элемента управления экономикой страны, тесно связано с изменениями, происходящих в различных отраслях производства и экономики. Перемены в экономике страны происходят как на микроэкономическом уровне (на различных предприятиях страны), так и на макроэкономическом уровне (в отраслях экономики).
Организация информационных технологий управления является необходимым условием функционирования рыночной экономики на современном этапе развития страны. При этом большое значение имеет их исполнение в управлении предприятием, бухгалтерском учете, статистике, банковском деле, налогообложении, в социальной сфере, и т.д.
Основная задача информационных технологий управления - в результате целенаправленных действий по переработке первичной информации получить информацию нового качества, на основе которой вырабатываются оптимальные управленческие решения.
Целью выполнения курсовой работы является разработка конфигурации, которая позволит автоматизировать процесс управления в ИТ организации, реализовать основные задачи, минимизировать количество ошибок сотрудников, тем самым повысив качество обслуживания клиентов.
Результатами выполнения курсовой работы должна стать готовая конфигурация, отвечающая всем требованиям технического задания.
Данная конфигурация может быть использована сотрудниками предприятий различного масштаба.
1. Функциональный анализ предметной области
1.1 Теоретические основы проектирования прикладных решений на платформе «1С: Предприятие 8.3»
Термин «1С: Предприятие» обозначает систему ПО, в которую входят и платформа, и наборы прикладных решений (разного масштаба и разной отраслевой специфики), а также различных методик. Поэтому как про средство разработки правильно говорить именно про платформу «1С: Предприятие». Как и для многих современных платформ, для «1С: Предприятия» трудно провести определенную границу между собственно инструментом разработки и «исполняющей системой», поскольку они образуют единое целое. Фактически платформа и есть средство разработки, но работает она как на этапе создания программ, так и при их выполнении [2].
Платформа «1С: Предприятие» содержит такие инструменты для выполнения поставленных задач, как визуальное описание структур данных, написание программного кода, визуальное описание запросов, визуальное описание интерфейса, описание отчетов, отладка программного кода, профилирование. В ее составе: развитая справочная система, механизм ролевой настройки прав, инструменты создания дистрибутивов, удаленного обновления приложений, сравнения и объединения приложений, ведения журналов и диагностики работы приложения, создания Web-приложений и приложений для КПК, а также поддержка коллективной разработки, версионирования и пр.
Разработка в «1С: Предприятии» строится на основе общей модели работы приложения, предлагаемой платформой «в обязательном порядке», т.е. основные и наиболее сложные архитектурно-технологические решения (такие, как механизм трехуровневой архитектуры, вопросы взаимодействия компонентов, аутентификация пользователей и т.д.) предлагаются разработчикам в готовом виде.
Проанализируем особенности платформы «1С: Предприятие» с точки зрения критериев выбора средства разработки. Прежде всего, ее использование стоит рассматривать для решения тех задач, для которых оно предназначено, - автоматизации управления и учета. Конечно, есть и весьма успешные случаи нестандартного применения системы для других областей, но не будем на них отвлекаться. Далее, важный критерий выбора между «1С: Предприятием» и универсальными средствами разработки - по нашему мнению, оценка затрат на разработку и сопровождение системы. При этом затраты вполне можно оценить количественно. Скорость разработки в «1С: Предприятии» обычно выше в 2-10 раз и стоимость соответственно в разы ниже.
Но можно оценить и качественно. При разработке на универсальных средствах нужно вырабатывать целый спектр технологических и архитектурных решений. Как минимум, чтобы выбрать необходимые шаблоны проектирования и технологии и увязать их между собой. А это соответственно, кроме затрат времени, потребует наличия специалистов с соответствующими профессиональными навыками. При разработке приложения на «1С: Предприятии», разумеется, тоже нужны квалифицированные специалисты в предметной области и прикладной разработке, но такие специалисты, разумеется, понадобятся и при разработке на универсальных средствах.
Особо стоит отметить преимущества предметно-ориентированной среды на этапе поддержки системы. Наличие стандартизованной модели позволяет с существенно меньшими затратами развивать функциональность и включать в работу новых специалистов. Если представить себе стек технологий (от работы с базой данных, коммуникаций с сервером, управлением интерфейсом), то разработчик в среде «1С: Предприятие» будет существенно лучше понимать устройство конкретного приложения при первом знакомстве с ним, так как он знает общую технологическую и прикладную модель его построения.
1.2 Управленческая характеристика предметной области конфигурирования
Решение для ИТ-подразделений любой организации и ИТ-компаний занимающихся обслуживанием клиентов. Содержит в себе полный комплекс средств для работы службы технической поддержки: программистов, системных администраторов, техников компьютерных сетей. Решение позволяет эффективно организовать их работу и взаимодействовать с сотрудниками организаций.
Простота и удобство работы сделают данную конфигурацию незаменимым помощником в любой IT-структуре.
Конфигурация прекрасно зарекомендовала себя как в маленьких организациях, так и в достаточно крупных холдингах.
Основные возможности:
· Заказы поставщикам, контроль их оплаты и поставки;
· Соглашение на предоставление сервиса;
· Возможность формирования аналитических отчетов;
· Формирование счетов на оплату;
· Количественный и суммовой учет номенклатуры по материально-ответственным лицам;
· Возможность вести учет сразу по нескольким организациям;
· Проведение обслуживания, как собственными силами, так и силами сторонних организаций;
· Оплата и контроль услуг сторонним организациям за ремонт и обслуживание;
· Обслуживание на рабочем месте, где произошла проблема и отражение этого факта в программе;
· База клиентов, поставщиков.
1.3 Проектирование комплекса функциональных подсистем конфигурации
Основу интерфейса составляют подсистемы нашего прикладного решения, которые разбивают нашу конфигурацию на отдельные функциональные части. В данной курсовой использовались следующие подсистемы (Рис. 1).
Рис. 1. Подсистемы
Первая подсистема называется «SLA» (Рис. 2).
Здесь мы можем просмотреть базу предоставляемых сервисов. Принимаем заказы на определенный сервис и здесь же выписываем счета на оплату. В этой подсистеме доступны все аналитические отчеты.
Вторая подсистема называется «Заказы поставщикам» (Рис. 3).
Рис. 3. Поставщики
Здесь можно просмотреть базу поставщиков, оформить заказ, а также заказ по доверенности если ответственное лицо не может забрать заказ. В этой же подсистеме формируются покупки клиентов.
Третья подсистема называется «Сотрудники» (Рис. 4).
Здесь можно просмотреть набор должностей, имеющихся в нашем клубе, просмотреть базу сотрудников, базу банков, сотрудничающих с нашей организацией.
Четвертая подсистема называется «Техническая поддержка» (Рис. 5).
Рис. 5. Поддержка
Самая объемная подсистема. В ней отражаются сведения о сервисах, клиентах, об их покупках, а также остатков материалов в организации. Доступны все аналитические отчеты.
2. Разработка объектной модели предметной области
2.1 Конфигурирование системы хранения условно-постоянной информации
Объекты прикладного решения «Перечисление» позволяют хранить в информационной базе наборы значений, которые не изменяются в процессе работы прикладного решения.
Перечисления используются при вводе значений реквизитов документов, справочников, при вводе значений констант, в тех случаях, когда необходимо исключить неоднозначный ввод информации.
В конфигурации используются следующие перечисления (Табл. 1):
Табл. 1
В режиме конфигурации перечисление «Виды услуги» будет выглядеть следующим образом (Рис. 6):
Рис. 6. Перечисление «Пол»
Справочники
Объекты прикладного решения «Справочник» используются в системе для работы с условно-постоянной информацией с некоторым множеством значений.
Справочники позволяют хранить в информационной базе данные, имеющие одинаковую структуру и списочный характер.
В конфигурации используются следующие справочники:
§ «Состояния заказов клиентам»;
Справочник «Клиенты»
Данный справочник содержит список клиентов, когда-либо пользовавшихся услугами нашей организации.
Как оказалось, существует достаточно много неверных или не совсем точных, а иногда совсем неточных интерпретаций данного термина, что по сути искажает его. Вокруг этого диалога и родилась идея данной статьи. Подробности под катом.
Вопрос об архитектуре.
Подскажите как правильно архитектуру делать, вот допустим я сделал табличку в базе, попросил реформ сгенерировать мне реформ модель, могу я в своем приложении эту модель как домен модель использовать, или лучше создать свою домен модель и сделать адаптер который будет выдавать мне именно мою доменнную модель создавая ее из модели реформа?”
Прочитав это, я вдруг понял, почему вокруг так много споров в организации слоя бизнес-логики, и почему у многих не получается применять на практике такие подходы как Clean Architecture и т.п. Ведь что значит “архитектура с анемичной моделью”?
Если вы попробуете найти такое понятие в сети, вы его скорее всего не обнаружите, потому что такой архитектуры нет. Есть понятие “AnemicDomainModel”, и если обратится к тому же Фаулеру, окажется, что это просто процедурный подход к созданию архитектуры приложений (привет Fortran, ALGOL, COBOL, BASIC, Pascal и C). Это в сущности и есть то, что автор ответа называет “архитектура с анемичной моделью”.
Модель предметной области (домена).
Далее возникает следующий вопрос, а является ли “анемичная модель” моделью по сути? Я думаю, нет, и вот почему.
Правда заключается в том, что модель предметной области — это не модель данных, в отличие от “модели БД” или “модели ответа API”. Модель предметной области, имеет вполне конкретное определение. Тем более неправильно мешать ее с моделью БД, которая по сути является моделью данных.
Когда речь идет о модели предметной области, имеется ввиду именно концептуальная модель. А это совокупность понятий предметной области и отношений между ними (т.е. совокупность поведения и данных). В целом главной чертой, отличающей одну модель предметной области от другой, является именно набор бизнес-правил.
Да, концептуальная модель может работать с данными, которые представлены в разном виде (данные из БД или ответы API), но суть от этого не изменится, первостепенно поведение. Мы передаем на вход модели данные, чтобы получить определенный результат на выходе. Этот результат достигается с помощью реализации бизнес-логики внутри модели (другими словами применения бизнес-правил). Я нахожу здесь аналогию с математическими моделями и моделированием технологических процессов (привет студенческие годы).
Чем чревата подмена понятий?
Когда вы называете структуры данных “моделью домена”, вы вольно или нет подменяете понятия. Это приводит к тому, что зачастую бизнес-логика размазывается по всему приложению. На самом деле, моделью предметной области в таком случае является тот самый размазанный набор функций, оперирующий структурами данных.
В случае разработки средних и больших приложений, непонимание или смешивание этих понятий, как правило, приводит к ряду проблем и вопросов уже на старте разработки системы, не говоря уже о долгосрочной поддержке. Среди них, к примеру, встречаются такие распространенные вопросы как:
- "- Где валидировать данные?"
- "- Как избежать циклических зависимостей?"
- "- А является ли “это” бизнес логикой вообще?"
- "- А где у нас хранится бизнес-логика?"
- и т.п.
Если вернуться к тому, что диалог о моделях предметной области возник в Go комьюнити, я бы сказал так. В силу того, что Go является мультипарадигменным языком и поддерживает ряд наиболее удачных ООП концепций (Композиция, Интерфейсы), не стоит игнорировать их при моделировании предметной области и писать код исключительно в процедурном стиле, как будто вы работаете с BASIC или С.
Правильно интерпретируя понятие “модель предметной области” становится вполне очевидно, почему зачастую принято выделять бизнес-логику в отдельный слой. Так же становится понятно, каким образом можно выделить этот самый слой и реализовать Clean Architecture или любую другую ее вариацию. Выделяя отдельный слой, мы по сути создаем библиотеку, которая реализует концептуальную модель в виде программного кода. Как результат, бизнес-логика становится инкапуслирована в рамках этой библиотеки, а не размазана по всему приложению (как при чистом процедурном подходе).
Конечно, понимание этих концепций не избавит вас от ошибок при проектировании, не сделает из вас идеального разработчика или системного архитектора и не научит делать все правильно с первого раза. Здесь важна не только теория, но и практика. Тем не менее, как только вы правильно поймете концепции и интерпретируете определения, многие вещи станут для вас на порядок очевиднее и проще.
Подведем итоги.
- Не корректно называть «данные» моделью предметной области.
- Модель предметной области — это концептуальная модель, которая включает в себя как поведение, так и данные. Она может быть инкапсулирована в отдельный слой, а может быть размазана по всему приложению.
- “Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению
Всем добра! Спасибо за внимание.
PS. Буду рад выслушать конструктивную критику, а так же ваше видение того, что такое «модель предметной области». Ссылки на первоисточники приветствуются.
UPD: Статья не является попыткой вольной интерпретации понятия «модель предметной области» и вкладывания в это понятие одному мне известного смысла. Я хочу донести вот что: Смысл в данное понятие давно вложен, и оно подробно описано в книгах и статьях по ComputerScience. Статья является попыткой донести до коллег по цеху важность правильного восприятия этих самых концепций не искажая их смысл (Это важно, потому что на практике позволит писать более осмысленный код).
UPD3: Т.к. многие интерпретируют термин «предметная область» по разному, привожу некоторые примеры предметных областей, чтобы не было путаницы и подмены понятий. Предметная область всегда зависит от того, какую проблему вы решаете с помощью разработки приложения:
Под объектом конфигурациив системе «1С: Предприятие» понимаетсяформальное описание группы понятий (предметной области, средств взаимодействия пользователя с системой) со сходными характеристиками и одинаковым предназначением.
Все объекты конфигурации можно подразделить на три основные группы: общие, прикладные, подчиненные
1) Общие объекты.Группа вспомогательных объектов конфигурации, с помощью которых осуществляется создание конфигурации, механизмов взаимодействия пользователей с учетными данными.
2) Прикладные объекты.Их перечень можно увидеть на первом уровне дерева метаданных (исключая группу «Общие»).
3) Подчиненные объекты.К таким объектам относятся «Реквизиты», «Табличные части» и т.д.
Прикладные объекты (или объекты метаданных)
Под объектом метаданных понимается формальное описание неких сущностей предметной области автоматизации со сходными свойствами и одинаковым назначением.
Например: для описания модели предметной области бухгалтерского учета используются следующие виды объектов метаданных:
1) Константы - для хранения постоянной или условно-постоянной информации;
2) Справочники -для хранения сведений о множестве однородных объектов;
3) Перечисления - для описания наборов постоянных значений, не изменяемых пользователем в процессе работы с программой;
4) Документы -для отражения информации о различных фактах хозяйственной деятельности организации (служат для ввода информации о совершаемых операциях в системе);
5) Журналы документов - для удобного отображения списков документов;
6) Планы видов характеристик -для описания множеств однотипных объектов аналитического учета (описание настройки пользователей, перечень видов субконто и т.д.).
7) Планы счетов -для описания совокупности синтетических счетов, предназначенных для группировки информации о хозяйственной деятельности организации по определенным признакам.
8) Регистры сведений - для хранения существенной для прикладной задачи информации, состав которой развернут по определенной комбинации значений, а при необходимости — и во времени;
9) Регистры накопления- для учета информации о наличии и движении каких-либо величин: материальных, денежных и др.;
10) Регистры бухгалтериииспользуются для того, чтобы показать, каким образом информация о хозяйственных операциях отражается в учете;
11) Отчеты -для получения результатной информации по некоторому алгоритму, описанному на встроенном языке системы
12) Обработки -для выполнения различных сервисных и регламентных действий над информацией.
Подчиненные объекты
В зависимости от вида объекта конфигурации (прикладного или общего) он может иметь различные подчиненные группы объектов.
Приведем перечень подчиненных объектов:
Реквизиты- дополнительная информация об объекте, доступная только в пределах этого объекта. Можно сказать, что с помощьюреквизитов можно определить дополнительные свойства объекта.
Табличные части- наборы дополнительной информации об объекте, представленные в виде таблиц.
Реквизиты табличных частей- состав табличной части объекта,доступны только в пределах табличной части объекта.
Формы- используются для ввода, просмотра и редактирования информации.
Команды - используются для реализации каких-либо действий, принадлежащих объекту.
Макеты- предназначены для формирования печатных форм объекта.
Графы- графы журнала документов.
Измерения- для регистров это объекты конфигурации, в разрезе которых учитываются данные в регистре.
В статье рассмотрены возможности моделирования бизнеспроцессов предприятия сферы услуг с помощью технологической платформы 1С:Предприятие. На конкретном примере салона красоты выделены информационные потоки. Разработана структура информационной базы с использованием основных объектов конфигурации 1С:Предприятие.
В каждой, даже самой маленькой организации, ведется учет совершаемых операций. Сегодня благодаря информационно-коммуникационным технологиям, которые являются инструментами для формирования электронной информационной среды предприятия, появляется возможность упрощения введения хозяйственных операций, к чему и стремится любая организация.
Для автоматизации деятельности самых различных организаций и предприятий в российской экономике наиболее часто используется система 1С: Предприятие 8.3, с помощью, которой создаются или адаптируются самые разнообразные бизнес-приложения.
Разработка информационной системы для конкретного предприятия начинается с анализа его деятельности. С целью выявления точек дублирования, избытка и недостатка информации, причин сбоев и задержек в ее получении необходимо проанализировать информационные потоки предприятия, т.е. рассмотреть все процессы возникновения, движения и обработки информации, а также направленность и интенсивность документооборота.
Каждый информационный поток, представляющий собой единичное перемещение информации, имеет следующие параметры:
- документ (физический носитель информации);
- проблематика (к какой сфере деятельности предприятия относится информация: к закупкам, к сбыту продукции, к закрытию месяца и получению сводных затрат, к планированию и т.д.);
- исполнитель (человек, который эту информацию передает);
- периодичность (частота передачи: ежемесячно, ежеквартально, ежедневно).
В деятельности предприятия сферы услуг, а именно салона кра- соты,можно выделитьинформационные потоки, относящиеся к таким подсистемам, как:
- «Сотрудники»;
- «Услуги»;
- «Материалы».
Одно из главных требований, предъявляемых к разрабатываемой информационной системе (ИС), это - надежность и целостность данных, ведь ядром информационных систем являются хранимые данные. Удобство пользователя при работе с ней является еще одним из важнейших требований, поэтому ИС должна содержать удобный пользовательский интерфейс и обеспечивать:
- полноту информации, предоставляемой пользователям;
- полезность и ценность информации;
- своевременность поступления информации;
- экономичность и эффективность обработки информации;
линейный вид, особенностью которого являются большая ответственность и нагрузка на руководителя и администратора салона. Для оптимизации работы салона необходимо автоматизировать деятельность администратора, так как именно от результатов его работы зависит оптимальная загрузка мастеров и удовлетворенность клиентов.
Автоматизация ведения бизнес-процессов позволит повысить производительность работы всего салона в целом, так как с помощью нее решаются следующиенемаловажные задачи:
- 1. Сокращение трудозатрат
- 2. Ведение клиентской базы
- 3. Сокращение ошибок
- 4. Доступность и оперативность информации для принятия решений
Предприниматель без информации о текущем состоянии дел, без статистических данных, анализов и отчетов, не сможет добиться развития своего бизнеса. Принятие управленческих решений требует наличия достоверной и актуальной информации в любой момент времени, что сможет обеспечить лишь использование информационной системы.
Структурно-функциональная модель информационной системы разрабатывается с учетом типа услуг, предоставляемых салоном и его специфики с целью эффективного и результативного выполнения стоящих перед ней задач. При моделировании бизнес-процессов салона красоты были использованы такие объекты конфигурации как подсистемы, справочники, регистры и отчеты. На рис.2 представлена схема информационной базы бизнес-приложения «Салон красоты».
8. Перечислите и охарактеризуйте основные операции реляционной алгебры?
9. Где используются операции реляционной алгебры?
Процесс конструирования базы данных (ее проектирования и реализации) состоит из последовательности преобразований модели данных одного уровня в модель данных другого уровня.
Последовательности преобразований модели данных:
- систематизация объектов реального мира;
- создание информационных структур, описывающих систему объектов реального мира;
- создание структуры данных, которая используется для представления информационных структур в базе данных и прикладных программах;
- представление структуры памяти, используемой для хранения структур данных.
Процесс проектирования базы данных включает три этапа:
Первый этап - анализ предметной области или этап концептуального проектирования. На этапе концептуального проектирования осуществляется сбор, анализ и редактирование требований к данным.
Первым этапом проектирования БД любого типа является анализ предметной области, который заканчивается построением информационной структуры (концептуальной схемы). На данном этапе анализируются запросы пользователей, выбираются информационные объекты и их характеристики, которые предопределяют содержание проектируемой БД. На основе проведенного анализа структурируется предметная область. Анализ предметной области не зависит от программной и технической сред, в которых будет реализовываться БД.
Анализ предметной области целесообразно разбить на три фазы:
1) анализ требований и информационных потребностей;
2) выявление информационных объектов и связей между ними;
3) построение модели предметной области и проектирование схемы БД.
Рассмотрим каждую фазу данного этапа проектирования подробно. Анализ концептуальных требований и информационных потребностей
На этапе анализа концептуальных требований и информационных потребностей необходимо выполнить;
1) анализ требований пользователей к базе данных (концептуальных требований);
2) выявление имеющихся задач по обработке информации, которая должна быть представлена в базе данных (анализ приложений),
3) выявление перспективных задач (перспективных приложений);
4) документирование результатов анализа
Требования пользователей к разрабатываемой БД представляют собой список запросов с указанием их интенсивности и объемов данных. Эти сведения разработчики БД получают в диалоге с ее будущими пользователями. Здесь же выясняются требования к вводу, обновлению и корректировке информации Требования пользователей уточняются и дополняются при анализе имеющихся и перспективных задач.
Рассмотрим примерный состав вопросника, требований к базе данных при анализе различных предметных областей.
Пример 1. Пусть предлагается разработать систему вопросов к БД «Сессия студентов колледжа»:
1. Сколько студентов учится в колледже?
2. Сколько отделений в данном колледже?
3. Как распределены студенты по отделениям отделений и курсам?
4. Сколько дисциплин читается на каждом курсе по каждой специальности?
5. Как часто обновляется информация в базе данных?
6. Сколько преподавателей?
7. Сколько иногородних студентов живет в общежитии, на частных квартирах?
8. Какая преемственность существует между читаемыми курсами?
9. Сколько лекционных аудиторий и аудиторий для проведения практических занятий, лабораторий?
10. Как информация, представленная в п.п. 1-9, используется в настоящее время (расписание занятий, экзаменов, зачетов и т.д.) и как ее собираются использовать?
11. Сколько раз в день, сколько человек и кто пользуются БД?
Пример 1 (продолжение). Выполним анализ требований к БД «Сессия студентов». Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информация о студентах. Задача 2. Информация о преподавателях. Задача 3. Информация об успеваемости студентов. Задача 4. Информация о предметах.
Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется информационным объектом: личные дела студентов. Задача 2 характеризуется информационным объектом: личные дела преподавателей. Задача 3 характеризуется одним информационным объектом - сессия. Задача 4 характеризуется одним информационным объектом - предметы.
Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты?
Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Сессия студентов»?
Пример 2. Пусть требуется разработать требования к локальной БД «Аэропорт».
Вопрос 1. Для каких типов задач (приложений) проектируется БД? Ответ. Для трех типов задач: Задача 1. Информацияоб обслуживающем персонале. Задача 2. Информация о полетных средствах Задача 3. Информация о графике движения самолетов.
Вопрос 2. Какими информационными объектами характеризуются эти задачи? Ответ. Задача 1 характеризуется тремя информационными объектами: летный состав, диспетчеры, технический персонал. Задача 2 характеризуется двумя информационными объектами: самолет, взлетное поле. Задача 3 характеризуется одним информационным объектом - рейсы.
Вопрос 3. Каким текущим запросам должны удовлетворять данные информационные объекты? Ответ.
1. ФИО, звание, должность членов экипажа самолета.
2. Списочный состав диспетчеров.
3. Состав смены технического персонала.
4. Тип самолета, который может обслуживать тот или иной пилот.
5. Номер самолета, который обслуживает данный пилот, данная смена диспетчеров и технического персонала.
6. Номер личного дела сотрудника аэропорта.
7. Номер смены диспетчеров и технического персонала, обслуживающего аэропорт в заданном интервале времени.
8. Готовность самолета с номером № к полету.
9. Количество часов налета самолета с № .
10. Готовность данной взлетной полосы в настоящее время.
11. Длина данной полосы.
12. Номер (номера) рейса до данного пункта назначения.
13. Какие промежуточные посадки совершает рейс № ?
14. Время вылета и расчетное время прибытия рейса № .
15. Время и место регистрации рейса №
16. Время посадки на рейс № .
17. До какого времени задерживается рейс № ?
18. Какие типы самолетов обслуживают рейс №. ?
19. Какой номер самолета обслуживает рейс N°. ?
Вопрос 4. Каким перспективным запросам должны удовлетворять информационные объекты в БД «Аэропорт»?
1. С какого года используется самолет с № в аэропорту, тип самолета?
2. Какое количество часов полета у члена экипажа, ФИО?
Расчетное время отпуска члена экипажа, диспетчера, технического работника.
Выявление информационных объектов и связей между ними
Вторая фаза анализа предметной области состоит в выборе информационных объектов, задании необходимых свойств для каждого объекта, выявлении связей между объектами, определении ограничений, накладываемых на информационные объекты, типы связей между ними, характеристики информационных объектов.
При выборе информационных объектов следует ответить на следующие вопросы:
1. На какие классы можно разбить данные, подлежащие хранению в БД?
2. Какое имя можно присвоить каждому классу данных?
3. Какие наиболее интересные характеристики (с точки зрения пользователя) каждого класса данных можно выделить?
4. Какие имена можно присвоить выбранным наборам характеристик?
В ходе выявления связей между информационными объектами следует ответить на следующие вопросы:
1. Какие типы связей между информационными объектами?
2. Какое имя можно присвоить каждому типу связей?
3. Каковы возможные типы связей, которые могут быть использованы впоследствии?
4. Имеют ли смысл какие-нибудь комбинации типов связей?
Далее проектировщик пытается задать ограничения на объекты и их характеристики. Под ограничением целостности обычно понимают логические ограничения, накладываемые на данные. Ограничение целостности - это такое свойство, которое проектировщик задает для некоторого информационного объекта или его характеристики, и которое должно сохраняться для каждого их состояния.
При выявлении условий ограничения целостности проектировщик пытается ответить на следующие вопросы:
1. Какова область значений для числовых характеристик?
2. Каковы функциональные зависимости между характеристиками одного информационного объекта?
3. Какой тип отображения соответствует каждому типу связей?
Пример 1 (продолжение). Для БД «Сессия студентов» выберем следующие сущности: институт, факультет, студент, преподаватель, дисциплина, ведомость. Каждую сущность зададим набором атрибутов (ключевые атрибуты подчеркнем): институт (сокращение , название, подчиненность, адрес, телефон, ФИО ректора).
факультет (код Факультета , название, код специальности, декан). кафедры факультета (код кафедры , название, код факультета, зав.кафедрой). студент (номер зачетной книжки , ФИО, группа, пол, дата рождения, домашний адрес, телефон).
дисциплина (шифр дисциплины , название, число часов, виды занятий, число читаемых семестров, на каких курсах преподается).
ведомость (№ п/п, номер зачетной книжки студента, код дисциплины, семестр, форма сдачи, дата сдачи, отметка, преподаватель). Определим связи между сущностями.
Имя связи учится изучает принадлежит |
Связи между объектами
студент, факультет студент, дисциплина институт, факультет |
работает преподает экзамен |
Рассмотрим некоторые ограничения на характеристики объектов:
1. Значение атрибута "телефон" (сущность - институт) задается целым положи
тельным шестизначным числом, задавать значение будем по маске __-__-__ .
2. Значение атрибута "код факультета" (сущность факультет) лежит в интервале
0-10.
3. Значение атрибута "курс" (сущность - студент) лежит в интервале 1-6 и хранится первая цифра номера группы.
4. Значение атрибута "семестр" (сущность - студент, дисциплина) лежит в интервале 1-12.
5. Значение атрибута "число часов" (сущность - дисциплина) лежит в интервале 1-300.
6. Одному студенту может быть приписана только одна группа.
7. Один студент может учиться только на одном факультете.
8. Один студент в семестре сдает от 3 до 10 дисциплин.
9. Один студент изучает в семестре от 6 до 12 дисциплин.
10.Одному преподавателю приписывается только одна кафедра.
11.Один студент может пересдавать одну дисциплину не более трех раз.
Ключи: сокращение (названия института), код факультета, номер зачетной книжки, № страхового свидетельства преподавателя, шифр дисциплины, № п/п.
Построение концептуальной модели предметной области
Заключительная фаза анализа предметной области состоит в проектировании ее информационной структуры или концептуальной модели.
Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в, рассматриваемой предметной области (ПО) и выявляемых в результате анализа данных. Концептуальная модель применяется для структурирования предметной области с учетом информационных интересов пользователей системы. Она дает возможность систематизировать информационное содержание предметной области, позволяет как бы "подняться вверх" над ПО и увидеть ее отдельные элементы.
При этом, уровень детализации зависит от выбранной модели. Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений. Концептуальная модель должна быть стабильной. Могут меняться прикладные программы, обрабатывающие данные, может меняться организация их физического хранения, концептуальная модель остается неизменной или увеличивается с целью включения дополнительных данных.
Одной из распространенных моделей концептуальной схемы является модель «сущность-связь». Остановимся на наиболее известной модели данного типа, названной по фамилии автора, - модели П. Чена, или ER-модели. Основными конструкциями данной модели являются сущности и связи.
Под сущностью понимают основное содержание объекта ПО, о котором собирают информацию. В качестве сущности могут выступать место, вещь, личность, явление. Экземпляр сущности - конкретный объект. Например: сущность (объект) - студент, экземпляр сущности - Иванов А. В.; сущность (объект) - институт, экземпляр сущности - КГУ.
Сущность принято определять атрибутами - поименованными характеристиками. Например: сущность - студент, атрибуты - ФИО, год рождения, адрес, номер группы ит.д.
Чтобы задать атрибут в модели, ему надо присвоить имя и определить область допустимых значений. Одно из назначений атрибута - идентифицировать сущность.
Читайте также: