Роль проектирования данных в жизненном цикле информационных систем

Составные части процесса проектирования данных

Процесс проектирования данных можно условно разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания.

Логическое моделирование

Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы.

С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми.

На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.

Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ», где существительными являются названия связанных между собой сущностей.

Подавляющее большинство средств проектирования данных позволяют создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью мыши. Интерфейс таких средств нередко настолько прост, что позволяет освоить логическое проектирование данных не только разработчику, но и пользователю-непрограммисту, если таковой участвует в проектировании данных как эксперт в предметной области.

Отметим, что на этапе логического проектирования можно описать поведение СУБД при нарушении правил ссылочной целостности, определяемых данной связью (например, при удалении сведений о заказчике, разместившем хотя бы один заказ, для связи). Для этого многие средства проектирования данных обладают языком шаблонов, не зависящим от СУБД, на котором можно описать алгоритм обработки подобной ситуации, например с помощью соответствующих триггеров или иных объектов базы данных, а также набором стандартных шаблонов, реализующих некоторые типовые алгоритмы подобной обработки (например, отказ от удаления с последующей генерацией диагностического сообщения, каскадное удаление дочерних записей и др.). В процессе создания физической модели (о ней будет рассказано чуть ниже) эти шаблоны преобразуются в код на процедурном расширении языка SQL, применяемом в конкретной СУБД.

Ряд публикаций проводит градацию категорий логических моделей по степени детализации описания сущностей, атрибутов и связей. Модель, обсуждаемая с заказчиком, являющимся обычно экспертом в подлежащей автоматизации предметной области, а не программистом или аналитиком, должна содержать, например, основные сущности и связи, но не обязана иметь их детальную техническую проработку (в частности, описания алгоритмов обработки нарушений ссылочной целостности). В то же время модель, служащая основой технического задания на разработку клиентских приложений, обязана содержать детальное представление структуры данных, ключевых атрибутов, их текстовое описание, а также представлять сущности в нормализованном виде (иногда такая модель называется полной атрибутивной моделью). Иными словами, нормализация модели данных обычно происходит на этапе логического проектирования.

Отметим, что логическая модель данных, как правило, не связана с конкретной СУБД и не учитывает технические особенности конкретных платформ, применяемых при ее последующей физической реализации.

ERwin (Computer Associates)

ERwin разработан компанией Logic Works, которая в 1988 году была приобретена фирмой Platinum Technologies, а ее, в свою очередь, приобрела компания Computer Associates. Этот продукт в течение последних десяти лет занимает лидирующие позиции среди средств проектирования данных.

ERwin представляет собой специализированное средство проектирования данных. Его применение предполагает, что моделирование бизнес-процессов и потоков данных производится с помощью других продуктов (например, BPwin), c которыми можно осуществлять обмен сведениями о моделях.

ERwin не ориентирован на какую-то конкретную СУБД и поддерживает более 20 типов СУБД, включая СУБД всех ведущих производителей серверов баз данных (Oracle, Sybase, Microsoft, IBM, Informix), а также все популярные форматы настольных СУБД (включая dBase, Clipper, FoxPro, Access, Paradox), кроме, возможно, самых последних версий. Дело в том, что новые версии ERwin не выпускались уже довольно давно— как минимум год не было обновлений имеющейся версии и более двух лет не выпускались новые версии этого продукта. Поэтому при использовании ERwin с последними версиями некоторых СУБД могут возникнуть проблемы (например, некоторые типы данных SQL Server 7.0 это CASE-средство поддерживает не совсем корректно). Тем не менее ERwin остается одним из самых популярных в мире продуктов этого класса благодаря поддержке большого количества платформ, простоте интерфейса и, что немаловажно, поддержке специфических особенностей организации физической памяти наиболее популярных серверных СУБД. Например, для СУБД Oracle, Microsoft SQL Server, Sybase этот продукт позволяет изменять местоположение и параметры хранения индексов, почти для всех популярных серверных СУБД создавать кластеризованные индексы и для многих из них— указывать характеристики табличных пространств и сегментов отката.

ERwin обладает встроенным макроязыком для написания в процессе логического проектирования не зависящих от СУБД шаблонов серверного кода, а также готовыми шаблонами для генерации триггеров, реализующих стандартные действия (например, каскадное удаление). При необходимости можно создавать и свои шаблоны триггеров, используя этот язык, причем каждая таблица может иметь свой набор шаблонов. При создании физической модели шаблоны преобразуются в код на процедурном расширении SQL того сервера, для которого создается физическая модель. Логическая и физическая модели ERwin хранятся в одном файле.

ERwin поддерживает обмен моделями с репозитарием Designer/2000 и Microsoft Repository, а также генерацию клиентских приложений для Visual Basic и PowerBuilder.

Помимо однопользовательской работы ERwin может выступать в роли клиентского приложения для другого CASE-средства— ModelMart, которое позволяет организовать коллективную разработку моделей данных, предоставляя для этой цели разделяемый репозитарий, хранящийся в одной из серверных СУБД.

Недавно компанией Computer Associates был выпущен новый продукт— ERwin Examiner, представляющий собой инструмент проверки баз данных и DDL-скриптов с целью выявления ошибок проектирования данных, сказывающихся на целостности данных и производительности сервера, таких, например, как ошибки нормализации, противоречивые ключи и т.д. В результате проверки ERwin Examiner предлагает способы устранения найденных ошибок, генерируя соответствующие DDL-скрипты. На нашем CD-ROM вы можете найти статью Сергея Маклакова, посвященную этому продукту. Ознакомительные версии ERwin, ModelMart и ERwin Examiner вы также можете найти на нашем CD-ROM.

Заключение

В настоящей статье мы рассмотрели жизненный цикл информационных систем и убедились, что проектирование данных играет в нем ключевую роль. Мы также узнали, что представляют собой процессы логического (концептуального) и физического моделирования данных.

Помимо этого мы рассмотрели несколько наиболее популярных средств проектирования данных— как специализированных, так и входящих в состав комплексных CASE-средств. Изучение возможностей этих продуктов свидетельствует о том, что все они, обладая своими особенностями и имея в определенной степени различающиеся сферы применения, как правило, имеют и сходные черты, в число которых входят:

1.Поддержка создания логических моделей, не зависящих от СУБД, и генерации физических моделей на их основе.

2.Поддержка нескольких типов СУБД, включая не только серверные, но и настольные.

3.Поддержка специфических особенностей тех или иных СУБД ведущих производителей (генерация триггеров, управление физическим хранением данных).

4.Способность осуществлять обратное проектирование на основе либо имеющейся базы данных, либо имеющегося DDL-скрипта.

5.Возможность генерации отчетов и проектной документации на основе созданной модели.

6.Возможность сохранения модели в репозитарии, который во многих случаях может быть разделяемым.

7.Поддержка генерации кода для одного или нескольких средств разработки или языков программирования. Следует отметить, что в этом отношении самым популярным средством разработки является, по-видимому, Visual Basic.

Рассмотрев процесс проектирования данных и средства, с помощью которых можно его осуществить, мы можем приступить к изучению следующего этапа жизненного цикла информационных систем — разработке клиентских приложений. Именно ей и будет посвящена следующая статья данного цикла.

 

 

Оптовый заводской склад

На склад поставляются детали, выполненные из определенных материалов (литые), от заданного круга поставщиков (постоянных или случайных) из различных городов.

В качестве поставщиков могут выступать юридические лица и индивидуальные предприниматели, причем эти группы описываются своим набором характеризующих атрибутов; юридические лица – номер и дата гос. регистрации, наименование, юридический адрес, форма собственности; предприниматели – ИНН, ФИО, страховой полис, номер паспорта, дата рождения.

При оформлении поставки учитываются дата, количество и стоимость, вид упаковки и способ доставки (автотранспорт, ж/д транспорт, самовывоз), причем одна поставка может включать несколько видов деталей.

Поставщики переходят в разряд постоянных, если они совершили поставок на сумму свыше 1 000 000 рублей в год.

Осуществляется отпуск деталей в цеха завода с учетом даты, количества и номера цеха. Поддерживается актуальное количество товаров на складе.

Таблица 1. Роли пользователей и их функции
Роль	Функции
Менеджер	Ведение базы деталей, материалов, поставщиков
Инженер завода	Просмотр спецификаций деталей
Бухгалтер	Оплата поставок
Учетчик	Оформление поставки
Логист	Управление отпуском деталей в цеха завода

Рис. 1. Логическая модель базы данных в нотации IDEF1X

Методология IDEF1X – один из подходов к моделированию данных, основанный на концепции "сущность – связь" (Entity – Relationship), предложенной Питером Ченом в 1976 г.

Таблица 2.1. Основные элементы нотации IDEF1X
Сущность(Entity)	Графическое изображение
Независимая сущность	Наименование Уникальный идентификатор Атрибуты
Зависимая сущность	Наименование Ссылка на идентификатор (FK) Атрибуты
Связь(Relationship)	Графическое изображение
Неидентифицирующая связь
Идентифицирующая связь	Независ.
Связь «Многие ко многим»
Наследование (обобщение) Полное   Неполное	Родительск. -й

 

Независимая сущность – это сущность, уникальный идентификатор которой не наследуется из других сущностей. Изображается в виде прямоугольника с прямыми краями.

Зависимая сущность – это сущность, уникальный идентификатор которой включает по меньшей мере одну связь с другой сущностью. Например, строка документа не может существовать без самого документа (зависит от него). Изображается в виде прямоугольника с закругленными краями.

 

Методология IDEF1X ориентирована на проектирование реляционных моделей баз данных. В основе реляционной модели лежит понятие нормализованного отношения (таблицы). При этом сущности предметной области отображаются в таблицы базы данных (рис. 2), обладающие следующими свойствами:

§ нет одинаковых кортежей (строк), они различаются по уникальному идентификатору – первичному ключу;

§ кортежи (строки / записи) не упорядочены сверху вниз;

§ атрибуты (столбцы) не упорядочены слева направо; в операциях с таблицей ее строки и столбцы могут просматриваться в любой последовательности безотносительно их содержания и смысла;

§ все значения атрибутов – скаляры и имеют одинаковую природу (построены на одном домене).

Рис.

2. Таблица реляционной базы данных

Ключ - столбец или группа столбцов, значения которых однозначно идентифицируют каждую строку.

В одной таблице может быть несколько ключей: один первичный, посредством которого осуществляется связывание отношений, а другие – альтернативные. Свойства ключа:

§ уникальность (не может быть строк с одинаковым ключом);

§ неизбыточность (удаление любого атрибута из ключа лишает его свойства уникальности).

Реляционная база данных − это множество связанных между собой отношений. Связи задаются с помощью вторичных ключей (Foreign key – FK), т.е. атрибутов, которые в других отношениях являются первичными ключами (Primary key – PK).

Основные ограничения целостности реляционной модели:

§ атрибуты из первичного ключа не могут принимать неопределенное значение (целостность объектов);

§ вторичные ключи не могут принимать значения, которых нет среди значений первичных ключей связанной таблицы: если отношение R2 имеет среди своих атрибутов какой-то внешний ключ (FK), который соответствует первичному ключу (PK) отношения R1, то каждое значение FK должно быть равно одному из значений PK.

Введение

Задачей курса "Проектирование Баз Данных" является не изучение особенностей той или иной СУБД, а освоение технологий создания и работы с базами данных. Проектирование информационных систем всегда начинается с определения цели проекта.

Настоящий лабораторный практикум написан для студентов специальности «Вычислительная техника и программное обеспечение» с учетом комментариев и предложений студентов, а также использованием реальных примеров, созданных студентами.

Хорошая база данных не получается случайно, структура ее содержимого должна тщательно прорабатываться, поэтому в лабораторной работе №1 на базе MS Visio достаточно подробно рассмотрен пример анализа предметной области или ТЗ (технического задания) организации учебного процесса с использованием системы оценки освоения дисциплин для создания учебной базы данных. Также приводится подробное описание примера проектирования базы данных. На самом деле, проектирование базы данных — это важная часть работы с БД, даже хорошая СУБД будет плохо работать с неудачно спроектированной базой данных.

Вывод требуемой информации из базы данных формулируется в виде запросов. Универсальным языком запросов к MS SQL Server является язык структурированных запросов SQL (Structured Query Language). Следует отметить, что язык SQL имеет множество диалектов, порожденных различными разработчиками.

В качестве используемой СУБД в лабораторных работах применяется система управления базами данных MS SQL Server 2008, хотя в равной степени это могла быть любая из современных СУБД. В последней версии MS SQL Server 2008 используется диалект Transact SQL, который базируется на существующем на сегодняшний день стандарте SQL для реляционных баз данных, установленном ANSI - Американским национальным институтом стандартов SQL 2003 и очень близок к нему. В методических указаниях достаточно подробно рассмотрены вопросы создания скриптов самой базы данных на языке SQL, манипуляции данными от создания простых до конструирования сложных запросов по поиску информации в спроектированной базе данных на диалекте Transact SQL.

На сегодняшний день нет идеальной системы управления базами данных, имеющей как развитый интерфейс, так и оптимизированную структуру. СУБД MS SQL Server 2008 не имеет интерфейса с пользователем в обычном понимании. Однако эта система является высокоэффективным хранилищем с развитыми средствами работы с данными и возможностями создавать приложения для работы с базой данных непрофессиональным пользователям. В методических указаниях приведен пример настройки доступа к источнику данных СУБД MS SQL Server 2008 среды Delphi для создания клиентского приложения.

Задание на лабораторную работу

Спроектируйте модель данных учебного процесса в MS Visio: создайте представления «Преподаватели», «Кафедры», «Группы», «Студенты», «Предметы», «Учебный_процесс», «Успеваемость» и связи между ними на основании ER-диаграммы (Рисунок 1.1).

 

3.1 Концептуальное проектирование базы данных

 

Прежде чем реализовывать структуру базы данных в MS Visio, необходимо создать проект этой базы данных на контрольном примере.

Контрольный (или тестовый) пример представляет собой упрощенный вариант реальной задачи, просчитываемый вручную вплоть до получения конечного результата. В контрольном примере указываются требования к объему и составу данных используемой исходной информации и результатов решения, рассматриваются основные понятия проектирования, как части рабочей среды, системный анализ которой приведен ниже.

С помощью контрольного примера проверим постановку задач обработки данных и работоспособность отдельных программ и информационной системы в целом.

Очень часто проектированию данных не уделяют должного внимания. Правильно спроектированная БД облегчает управление данными и становится цен­ным поставщиком информации. Плохо спроектированная БД вероятнее всего станет накопителем избыточной информации, т. е. неоправданного дублирования данных. Избыточность, как правило, затрудняет выявление ошибок в данных.Доступность современного превосходного программного обеспечения баз данных дает возможность даже новичкам создавать базы данных и приложения баз данных. К сожалению, подход "разработка без проекта" становится причиной множества провалов. Как показывает практика, многие, если не все, ошибки в плохо спроектированных системах баз данных не могут устранить даже лучшие программисты и менеджеры. При этом даже превосходная система управления базой данных (СУБД), вероятнее всего, не поможет разрешить проблемы, порожденные или усиленные плохим проектированием. Можно провести аналогию со строительством: даже лучшие каменщики и плотники не смогут построить хорошее здание по плохому проекту [2]. Большинство проблем в системах управления базами данных чаще всего возникает из-за плохого проектирования. Поскольку хранилища данных (data warehouse) получают информацию от рабочих (операционных) баз данных, концепции, структура и процедуры хранилищ данных станут более обоснованными, если вы будете достаточно хорошо разбираться в структуре и реализации рабочих БД. Проектирование баз данных имеет чрезвычайно важное практическое значение, чем и объясняется то внимание, которое ему уделено в первой лабораторной этой книги.В принципе, в результате создания базы данных мы получим каким-то образом связанные между собой таблицы, которые обоснованы на анализе данных (data mining), который является важнейшим компонентом в новейших системах принятия решений. На этапе анализа концептуальных требований и информационных потребностей необходимо решить следующие задачи:· анализ требований пользователей к БД (концептуальных требований);· выявление имеющихся задач по обработке информации, которая должна быть представлена в БД (анализ приложений);· выявление перспективных задач (перспективных приложений);· документирование результатов анализа. Чтобы исследовать различные аспекты использования СУБД, мы с вами рассмотрим сложный пример, приближенный к действительности, – ведение электронной документации деканата учебного заведения (ВУЗа), содержащую информацию об учебном процессе обучения студентов в вузах. Каждый вуз решает данную задачу по-своему, чаще всего без использования баз данных. Наш пример не является реальным примером обучения студентов в АИЭС или другом вузе, однако очень близок к тем задачам, которые стоят в действительности перед деканатами АИЭС и других вузов.

Организация учебного процесса с использованием системы оценки освоения дисциплин характеризуется следующими особенностями: необходимо учитывать списки студентов групп; перечень изучаемых предметов; преподавательский состав кафедр, обеспечивающих учебный процесс; сведения о лекционных, практических и других видах занятий в каждой группе; результаты сдачи экзаменов по каждому из проведенных занятий. Учебная программа строится в соответствии с утвержденным графиком на каждую специальность до начала учебного процесса. Учебная программа включает предлагаемые на факультете обязательные и элективные курсы. Каждому студенту предлагается учебный план на основе рабочего, исходя из того, что в процессе обучения он должен набрать заданное количество кредитов.

 

Если в системе обрабатывается информация о студентах, сущностью может являться студент, если обрабатывается информация об экзамене, то сущность – экзамен и т.п. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе.

Так, например, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов.

Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ЭКЗАМЕН составляет класс сущностей ЭКЗАМЕН.

Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс.

Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств).

Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности:

Класс сущностей Экземпляр сущности

СТУДЕНТ

Фамилия Иванов

Дата рождения 21.05.87

Место рождения Нижний Новгород

 

Взаимоотношения сущностей выражаются связями (Relationships).

Различают классы связей и экземпляры связей. Классы связей – это взаимоотношения между классами сущностей, а экземпляры связи – взаимоотношения между экземплярами сущностей. Класс связей может затрагивать несколько классов сущностей.

Число классов сущностей, участвующих в связи, называется степенью связи n = 2, 3, … Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ЭКЗАМЕН связью «сдает». Степень этой связи равна двум. В качестве примера связи степени три можно указать связь «родители» между тремя классами сущностей МАТЬ, ОТЕЦ, РЕБЕНОК. При n=2 связь называется бинарной.

Рассмотрим классификацию бинарных связей.

Числа, которые описывают типы бинарных связей (1:1, 1:M, M:N), обозначают максимальное количество сущностей на каждой стороне связи. Эти числа называются максимальными кардинальными числами, а соответствующая пара чисел называется максимальной кардинальностью.

В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей:

· связь 1:1. Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь «соответствует» между классами сущностей ФАКУЛЬТЕТ и РАСПИСАНИЕ ЭКЗАМЕНОВ НА ФАКУЛЬТЕТЕ (каждому факультету соответствует свое расписание, эта тема сама по себе сложная и рассматриваться в данной книге не будет).

· связь 1:M. Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Примером является связь «обучение» между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете обучается много студентов).

· связь M:N. Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь «сдают» между классами сущностей СТУДЕНТ и ЭКЗАМЕН (каждый абитуриент сдает несколько экзаменов, и каждый экзамен сдают много студентов).

Чаще всего концептуальная модель представляется в виде диаграммы сущностей – связей (entity – relationship) или ER-диаграммы.

Процесс построения ER-диаграммы называется ER-моделированием. При этом используются следующие классические обозначения.

Класс сущностей представляется в виде четырехугольника. В четырехугольнике записано уникальное имя класса сущности (прописными буквами) и имена атрибутов строчными буквами, например:

 

СТУДЕНТ

Фамилия

Год рождения

Место рождения

 

Связи между сущностями обозначаются стрелками, рядом со стрелками указывается имя связи, а также максимальная кардинальность связи (максимальное число сущностей, которые могут участвовать в связи). Чтобы показать, что сущность обязана участвовать в связи (каждый экземпляр должен быть связан с экземпляром другого класса), на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал.

Отношения между группами, предметами и преподавателями с их мощностями представлены на следующей схеме (рисунок 1.1). Атрибуты объектов на схеме не указаны.

 

Рисунок 1.1 – Диаграмма учебного процесса

 

При описании сущностей обычно выделяют особые совокупности атрибутов – ключи и внешние ключи. Ключ уникально идентифицирует экземпляр сущности и, вместе с внешним ключом, используется для реализации связей. На диаграммах атрибуты, входящие в первичный ключ, подчеркиваются (обозначение РК).

Важность понятий ключа и внешнего ключа будет проиллюстрирована далее на примерах.

Приведенные выше обозначения не являются общеупотребительными. Часто производитель программ, позволяющих рисовать ER-диаграммы, использует свою систему обозначений. Например, при использовании программы MS Visio в качестве основной используется так называемая реляционная нотация. В данной системе обозначений связи обозначаются стрелками между сущностями и названия связей не пишутся. Название сущности выделяется цветом, поля, входящие в первичный ключ, отделяются чертой от остальных атрибутов. Обязательные атрибуты отображаются с помощью полужирного шрифта.

Кроме того, слева от атрибута указывается, входит ли данный атрибут в первичный ключ, а также является ли атрибут внешним ключом.

На практике использование различных способов записи ER-диаграмм не представляет особой сложности – беглое ознакомление с соответствующим разделом документации позволяет быстро освоить используемую систему обозначений.

 

При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее:

· необходимо понять, какая информация должна храниться и обрабатываться, и можно ли это определить как сущность;

· присвоить этой сущности имя;

· выявить атрибуты сущности и присвоить им имя.

· выявив сущности, необходимо определить, какие связи имеются между ними.

· при определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам обработки данных) необходимо учитывать следующее:

· то, как экземпляр одной сущности связан с экземпляром другой сущности;

· то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей).

 

На стадии начальной разработки БД большую часть полезной информации получают при опросе пользователей системы. Поэтому этап концептуального проектирования необходимо начать с выявления надежных источников информации. Составим список потенциальных пользователей системы.

Источники информации:

Администраторы БД – на основе официальных документов и отчетностей формируют структуру БД, изменяя и дополняя ее.

Преподаватели – предоставляют информацию.

Студенты – предоставляют информацию.

Сотрудники, не занимающиеся преподавательской деятельностью – предоставляют информацию.

В процессе анализа предметной области ОБУЧЕНИЕ СТУДЕНТОВ (не забывая, что это учебный пример и весь процесс глубоко не рассматривается) выделяются отдельные сущности.

Поскольку вещи одного типа хранятся в отдельных объектных множествах, можем выделить следующие сущности: СПЕЦИАЛЬНОСТИ, ГРУППЫ, СТУДЕНТЫ, КАФЕДРЫ, ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ, УЧЕБНЫЙ ПРОЦЕСС, УСПЕВАЕМОСТЬ.

В контрольном примере рассматривается только часть бизнес-правил учебного процесса.

В соответствии с предметной областью система строится с учетом следующих особенностей. Например:

· студент не может учиться на двух специальностях и в двух группах одновременно;

· не может быть двух студентов с одинаковыми номерами зачетной книжки;

· на кафедре работает много преподавателей;

· не может быть двух кабинетов с одинаковыми номерами;

· у кафедры не может быть несколько заведующих кафедрой;

· у группы может быть только один староста;

· по результатам промежуточной аттестации студенту выставляется дифференцированная оценка в принятой в вузе системе баллов, характеризующая качество освоения студентом знаний, умений и навыков по данной дисциплине;

· преподаватель может вести один и тот же предмет в нескольких группах или несколько разных предметов в одной группе;

 

Яндекс.Директ

Обучениелабораторномуделу!Дистанционная переподготовка и повышение квалификации. Начните обучаться сейчас!

Курсы дляучителей информатики!Дистанционные курсы дляучителей информатики. ФИПКиП! Диплом! Идет набор!

 

· студенты сдают экзамены по предметам, которые они изучали;

· у группы может быть только один куратор;

· преподаватель может занимать только одну должность;

· преподаватель может иметь только одну ученую степень;

· не может быть двух одинаковых специальностей;

· не может быть двух одинаковых ученых степеней;

· не может быть двух одинаковых должностей;

· группа занимается только по одному учебному плану.

 

Может быть сформулировано множество вопросов к базе данных, например: к какой группе относится студент, на каких кафедрах работают преподаватели, какие предметы, в каких группах они ведут, какую оценку получили студенты по определенным видам занятий по определенному предмету и т.д. Чтобы ответить на широкий круг возможных вопросов к базе данных, следует рассмотреть отношения между объектными множествами, необходимо присвоить связям имена и определить тип связей.

Между объектами ГРУППЫ и СТУДЕНТЫ существует отношение «один-ко-многим», поскольку одна группа включает много студентов, а один студент входит только в одну группу. Аналогично устанавливается связь между объектами КАФЕДРЫ и ПРЕПОДАВАТЕЛИ, которые также находятся в отношениях «один-ко-многим» (на одной кафедре работает много преподавателей, но каждый преподаватель работает на определенной кафедре). По каждому предмету проводится множество видов занятий в различных группах разными преподавателями. Это определяет отношения «многие-ко-многим» между множествами ГРУППЫ и ПРЕДМЕТЫ, ГРУППЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ПРЕПОДАВАТЕЛИ, ПРЕДМЕТЫ и ВИДЫ_ЗАНЯТИЙ.

Яндекс.Директ

Повышение квалификациипедагогов!Дистанционно. ФГОС. Скидки! Быстро! Лицензия. 2 документа: удостоверение и сертификат!СкидкиДокументы об окончанииОтзывыКонтактыpedcampus.ruАдрес и телефон

 

Пример построения подробной диаграммы «сущность – связь» для предметной области «Учебный процесс»

 

Исходя из выше изложенного, можно выделить следующие базовые сущности нашей предметной области, учитывая, что каждая таблица должна иметь первичный ключ:

· Специальности (SPECIALITY). Атрибуты – номер, название специальности. Эта сущность необходима, т.к. студент поступает в ВУЗ на специальность, а потом распределяется по группам.

· Группы (GRUP). Атрибуты этой таблицы – номер, название, количество студентов, курс. Эта сущность отводится для хранения сведений о группах. Так как названия групп формируются в зависимости от факультета, кафедры, года поступления и будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут Grup_ID – это ключевое поле, которое будет наращиваться на единицу при вводе в базу данных нового наименования.

· Студенты (STUDENTS). Эта сущность отводится для хранения сведений о студентах. Атрибуты – номер, фамилия, имя, отчество, дата рождения, адрес, номер группы, студент-староста. Stud_ID (идентификационный номер студента – обычно номер зачетной книжки) выбран в качестве первичного ключа (PK). Использование имени, фамилии и отчества в качестве идентификатора является неудобным решением, поскольку может появиться несколько однофамильцев. Это же правило относится к сочетанию фамилия-имя (отчества может не быть вообще). А учитывая, что идентификаторы студентов будут многократно встречаться в связях с другими сущностями базы данных, то их целесообразно нумеровать и ссылаться на эти номера.