Создание информационной системы, для выбранной предметной области

 Требования  и подходы к инфологическому  проектированию

 

Целью инфологического проектирования является создание структурированной  информационной модели ПО, для которой  будет разрабатываться БД. При  проектировании на инфологическом уровне создается информационно-логическая модель (ИЛМ), которая должна отвечать таким требованиям:

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

- корректность схемы БД, то есть адекватное отображение  моделированной ПО;

- простота и удобство  использования на следующих этапах  проектирования, то есть ИЛМ может  легко отображаться на модели  БД, которые поддерживаются известными  СУБД (сетевые, иерархические, реляционные  и др.);

- ИЛМ должна быть описана  языком, понятным проектировщикам  БД, программистам, администратору  и будущим пользователям.

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

Существует два подхода  к инфологическому проектированию: анализ объектов и синтез атрибутов. Подход, который базируется на анализе  объектов, называется нисходящим, а  на синтезе атрибутов — восходящим.

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

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

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

К инфологической модели предъявляются следующие  требования:

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

 

• непротиворечивость (модель отражает взгляды и потребности всех пользователей системы, а также обычно является результатом работы многих специалистов, поэтому целостное описание ПО должно быть проверено на непротиворечивость);
• однозначная трактовка модели всеми ее пользователями (обеспечивается формализованностью языка и четким его пониманием всеми участниками процесса создания ИС);
• легкость восприятия разными категориями пользователей (обеспечивается выбором соответствующего языка моделирования);
• конечность модели (несмотря на то, что реальный мир, отображаемый в КМ, является по своей природе бесконечным, инфологическая модель является конечной, что обеспечивается четким ограничением предметной области);
• легкость модификации (в концептуальную модель по разным причинам часто приходится вводить новые объекты или модифицировать существующие; КМ должна в связи с этим обладать свойством легкой расширяемости, обеспечивающим ввод новых данных без изменения раннее определенных.То же самое можно сказать и об удалении и корректировке данных);
• возможность композиции и декомпозиции модели.

Основные  понятия метода:

Основными понятиями  метода сущность-связь являются следующие:

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

ER-модель представляет  собой графическое описание предметной  области в терминах «объект  – свойство – связь». ER-модель  является одним из элементов  концептуальной модели.

В данной ИС отражена следующая  информация, представленная с помощью  ER-диаграммы.

1) Модель с тернарной связью Рис. 1

 

 

 

 

 

Рисунок 1 ER – диаграмма с тернарной связи.

2) Модель с бинарной связью Рис. 2

 

 

 

 

 

Рис. 2 ER – диаграмма с бинарной связью

 

3) Объединенные модели с бинарной связью (Рис. 3)

 

 

 

 

 

 

Рис. 3 Объединенная модель с бинарными связями.

4) Выделим следующие атрибуты  с бинарной сущности и связи: 

Атрибуты сущности Родители: Фамилия, Имя, Отчество, Дата рождения.

Атрибуты сущности Средства: Валюта, количество.

Атрибуты сущности связи Дети: Количество, пол, Фамилия, Имя,Возраст.

Связи зарабатывают и тратят не имеют атрибутов.

 

 

 

 

 

 

 

 

 

Глава 2.Создание информационной системы, для выбранной  предметной области.

2.1 Организация  ввода данных в базу данных.

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

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

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

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

Другой способ - идентификаторы полей размещаются друг за другом слева направо, а окошки располагаются  под ними (табличная форма). Такой  способ ввода данных имеет много  очевидных недостатков:

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

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

Ввод данных в таблицу  может быть осуществлен в режиме Таблица при работе с объектом Таблица.

Если таблица была создана  ранее и в настоящий момент она закрыта, то попасть в режим  Таблица можно, позиционировавшись на вкладке Таблица в окне БД на имени нужной таблицы и щелкнув  по кнопке Открыть.

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

Введенные данные автоматически  сохраняются при переходе к другой записи.

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

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

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

При организации ввода  данных важно не только выявить возможные  ошибки, но и организовать ввод таким  образом, чтобы предотвратить их.

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

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

2.2 Организация  корректировки базы данных.

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

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

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

Особую осторожность нужно  проявлять и при корректировке  проиндексированных файлов. Здесь надо обращать внимание на то, осуществляется ли корректировка индексного файла  одновременно с соответствующим  файлом БД системой автоматически. При  корректировке поля индексирования ввиду того, что записи в проиндексированных файлах обрабатываются в логической последовательности, а сама эта последовательность меняется в результате корректировки, может случиться, что не все требуемые  записи будут обработаны. В связи  с этим не рекомендуется делать операции по корректировке поля индексирования при активном индексе, особенно это  касается случаев, когда корректируются не единичные записи, а группа записей, отбираемых по условию FOR или WHILE. Даже если корректировка индексных файлов не приведет к некорректностям, нужно  избегать поддержания многих индексных  файлов открытыми, особенно при массовой корректировке, поскольку это замедляет  обработку.