ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 10.01.2024
Просмотров: 171
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Глава 1. Постановка задачи разработки информационной системы
1.1. Задание на разработку базы данных «Отдел кадров» института
1.2 Описание предметной области.
1.3. Обоснование необходимости создания БД
2.2. Концептуальная модель базы данных
2.3 Логическая модель базы данных. Нормализация.
2.4. Физическая структура базы данных.
Глава 3. Разработка программного обеспечения для ЭВМ
3.2. Экранные формы для ввода и редактирования данных в БД.
, ключ первой таблицы, называемый первичным, может вводиться в структуру второй таблицы, а ключ второй таблицы (внешний) может вводиться в первую таблицу.
Группировка данных в таблице может быть выполнена различными способами, однако она должна отвечать требованиям нормализации. Нормализацией называют формальный аппарат ограничений, применяемый при создании таблиц, применяемый при создании таблиц, позволяющий устранить дублирование и противоречивость хранимых данных и обеспечивающий эффективность их обработки. Нормализация – разбиение таблицы на две или более, обладающие лучшими свойствами включения, изменения или удаления данных. Окончательная цель нормализации сводится к получению такого проекта БД, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации.
Приведем наши отношения к третьей нормальной форме.
Первая НФ: Отношение называется нормализованным или приведенным к первой нормальной форме тогда и только тогда, когда все его атрибуты простые (неделимые). Таблица находится в первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом ее поле более одного значения, и не одно из ее ключевых полей не пусто. Для того чтобы привести наши отношения к первой нормальной форме надо сущность «ФИО» разбить на три отдельные (Фамилия, Имя, Отчество). Так же следует вынести в отдельную таблицу «Отделы/Кафедры», «Должности», чтобы не допустить избыточности данных. Таблицу «Сотрудники» разобьем на две таблицы: Сотрудники (личн_данные) и Сотрудники (труд_деят).
Вторая НФ: Таблица находится во второй нормальной форме, если она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Третья НФ: Таблица находится в третьей нормальной форме, если она удовлетворяет определению второй нормальной формы и ни одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля.
Отношения, представленные в данной БД приведены к третьей нормальной форме.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
База данных, состоящая из нескольких таблиц, должна иметь межтабличные связи, обеспечивающие целостность всех данных базы и автоматизацию задач обслуживания. Существуют три типа связей между таблицами базы данных:
Если записи однозначно определяются значениями нескольких полей, то такая база данных имеет составной ключ. Для связи реляционных таблиц ключ первой таблицы, ключ первой таблицы, называемый первичным, может вводиться в структуру второй таблицы, а ключ второй таблицы (внешний) может вводиться в первую таблицу.
Для атрибута «Вакансии» ключом будет являться три сущности, «Код вакансии», «Код отдела/кафедры», «Код должности», то есть ключ будет составным.
Для атрибута «Штатное расписание» ключом будет являться три сущности, «Код шт.ед.», «Код отдела/кафедры», «Код должности», то есть ключ будет составным.
Информационно-логическая модель данных – то модель данных, отображающая предметную область в виде совокупности информационных объектов и структурных связей между ними.
Таким образом, получим информационно-логическую схему данных, представленную в Приложении 2.:
Логическая структура базы данных - структура для пользователя, физическая - структура базы данных для ЭВМ. Физическая структура определяет, тип и свойства данных, которые будут записаны в память компьютера.
Правила перехода к физической модели следующие: каждое отношение превращается в файл базы данных, каждый столбец - в поле файла, каждая строка – в запись файла. Этап физического моделирования базы данных включает в себя определение состава файлов и их заполнение исходными данными в соответствии с ограничениями, допущениями и особенностями предметной области.
По сути дела физическое проектирование базы данных подразумевает конструирование таблиц в СУБД. СУБД Microsoft Access представляет собой систему управления базами данных, в состав которой входят таблицы, запросы, формы, отчеты, макросы и модули как самостоятельные объекты, хранящиеся в общем файле базы данных на жестком диске или любом другом носителе данных. Благодаря этому создание связанных объектов и проверка ссылочной целостности данных значительно облегчена.
В процессе физического проектирования БД необходимо присвоить имена таблицам, а также присвоить имена полям таблиц.
Так как первичный ключ – это некое поле (столбец) или группа полей таблицы базы данных, значение которого (или комбинация значений которых), используется в качестве однозначного уникального идентификатора записи (строки) этой таблицы, например, в таблице «Отделы/Кафедры в качестве первичного ключа целесообразно определить «Код отдела/кафедры», в таблице «Должности» - поле «Код должности», в таблице «Сотрудники
» - поле «Код сотрудника», в таблице «Кафедры» - поле «Код кафедры»
Структура необходимых таблиц представлена наглядно в таблицах:
Таблица 2 – Структура таблицы Отделы/Кафедры
Таблица 3 – Структура таблицы Должности
Таблица 4 - Структура таблицы Сотрудники(личн_данные)
Таблица 4 - Структура таблицы Сотрудники(труд_деят)
Таблица 5. Структура таблицы Вакансии
Таблица 6. Структура таблицы Штатное расписание
Группировка данных в таблице может быть выполнена различными способами, однако она должна отвечать требованиям нормализации. Нормализацией называют формальный аппарат ограничений, применяемый при создании таблиц, применяемый при создании таблиц, позволяющий устранить дублирование и противоречивость хранимых данных и обеспечивающий эффективность их обработки. Нормализация – разбиение таблицы на две или более, обладающие лучшими свойствами включения, изменения или удаления данных. Окончательная цель нормализации сводится к получению такого проекта БД, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации.
Приведем наши отношения к третьей нормальной форме.
Первая НФ: Отношение называется нормализованным или приведенным к первой нормальной форме тогда и только тогда, когда все его атрибуты простые (неделимые). Таблица находится в первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом ее поле более одного значения, и не одно из ее ключевых полей не пусто. Для того чтобы привести наши отношения к первой нормальной форме надо сущность «ФИО» разбить на три отдельные (Фамилия, Имя, Отчество). Так же следует вынести в отдельную таблицу «Отделы/Кафедры», «Должности», чтобы не допустить избыточности данных. Таблицу «Сотрудники» разобьем на две таблицы: Сотрудники (личн_данные) и Сотрудники (труд_деят).
Вторая НФ: Таблица находится во второй нормальной форме, если она удовлетворяет определению первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Третья НФ: Таблица находится в третьей нормальной форме, если она удовлетворяет определению второй нормальной формы и ни одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля.
Отношения, представленные в данной БД приведены к третьей нормальной форме.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
База данных, состоящая из нескольких таблиц, должна иметь межтабличные связи, обеспечивающие целостность всех данных базы и автоматизацию задач обслуживания. Существуют три типа связей между таблицами базы данных:
-
Связь один к одному (1:1) между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует единственная запись во второй таблице, и наоборот. Например, каждая запись в таблице «Сотрудники» может соответствовать единственной записи во второй таблице, включающей поля «Код сотрудника»; -
Связь один ко многим (1:М) между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует несколько записей во второй таблице. Например, одна запись в таблице «Сотрудники(личн_данные)» может соответствовать несколько записей в таблице «Сотрудники(труд_деят)». -
Связь многие ко многим (М:М). Такая связь между таблицами предполагает, что в каждый момент времени одной записи в первой таблице соответствует несколько записей во второй таблице, и одной записи во второй таблице соответствует несколько записей в первой таблице. Связь реализуется посредством создания третьей таблицы, в которой одно поле совпадает с ключевым полем первой таблицы, а второе – с ключевым полем второй таблицы.
Если записи однозначно определяются значениями нескольких полей, то такая база данных имеет составной ключ. Для связи реляционных таблиц ключ первой таблицы, ключ первой таблицы, называемый первичным, может вводиться в структуру второй таблицы, а ключ второй таблицы (внешний) может вводиться в первую таблицу.
Для атрибута «Вакансии» ключом будет являться три сущности, «Код вакансии», «Код отдела/кафедры», «Код должности», то есть ключ будет составным.
Для атрибута «Штатное расписание» ключом будет являться три сущности, «Код шт.ед.», «Код отдела/кафедры», «Код должности», то есть ключ будет составным.
Информационно-логическая модель данных – то модель данных, отображающая предметную область в виде совокупности информационных объектов и структурных связей между ними.
Таким образом, получим информационно-логическую схему данных, представленную в Приложении 2.:
2.4. Физическая структура базы данных.
Логическая структура базы данных - структура для пользователя, физическая - структура базы данных для ЭВМ. Физическая структура определяет, тип и свойства данных, которые будут записаны в память компьютера.
Правила перехода к физической модели следующие: каждое отношение превращается в файл базы данных, каждый столбец - в поле файла, каждая строка – в запись файла. Этап физического моделирования базы данных включает в себя определение состава файлов и их заполнение исходными данными в соответствии с ограничениями, допущениями и особенностями предметной области.
По сути дела физическое проектирование базы данных подразумевает конструирование таблиц в СУБД. СУБД Microsoft Access представляет собой систему управления базами данных, в состав которой входят таблицы, запросы, формы, отчеты, макросы и модули как самостоятельные объекты, хранящиеся в общем файле базы данных на жестком диске или любом другом носителе данных. Благодаря этому создание связанных объектов и проверка ссылочной целостности данных значительно облегчена.
В процессе физического проектирования БД необходимо присвоить имена таблицам, а также присвоить имена полям таблиц.
Так как первичный ключ – это некое поле (столбец) или группа полей таблицы базы данных, значение которого (или комбинация значений которых), используется в качестве однозначного уникального идентификатора записи (строки) этой таблицы, например, в таблице «Отделы/Кафедры в качестве первичного ключа целесообразно определить «Код отдела/кафедры», в таблице «Должности» - поле «Код должности», в таблице «Сотрудники
» - поле «Код сотрудника», в таблице «Кафедры» - поле «Код кафедры»
Структура необходимых таблиц представлена наглядно в таблицах:
Таблица 2 – Структура таблицы Отделы/Кафедры
| Поле | Тип данных | Комментарий |
| Код отдела/кафедры | Числовой | Ключ |
| Название отдела/кафедры | Текстовый | 60 |
Таблица 3 – Структура таблицы Должности
| Поле | Тип данных | Комментарий |
| Код должности | Счетчик | Ключ |
| Наименование должности | Текстовый | 25 |
Таблица 4 - Структура таблицы Сотрудники(личн_данные)
| Поле | Тип данных | Комментарий |
| Код сотрудника | Числовой | Ключ |
| Фамилия | Текстовый | 17 |
| Имя | Текстовый | 15 |
| Отчество | Текстовый | 15 |
| Пол | Текстовый | 5 |
| Дата рождения | Дата/время | Краткий формат даты |
| Домашний адрес | Текстовый | 35 |
| Семейное положение | Текстовый | Мастер подстановок |
| Количество детей | Числовой | Длинное целое |
| Паспортные данные | Текстовый | 11 |
| Телефон | Текстовый | 11 |
Таблица 4 - Структура таблицы Сотрудники(труд_деят)
| Поле | Тип данных | Комментарий |
| Код сотрудника | Числовой | Ключ |
| Код должности | Числовой | Поле со списком таблица «Должность» |
| Код отдела/кафедры | Числовой | Поле со списком таблица «Отделы/Кафедры» |
| Дата приема | Дата/время | Краткий формат даты |
| Дата увольнения | Дата/время | Краткий формат даты |
| Начало труд_деят | Дата/время | Краткий формат даты |
| Временно не работает | Логический | Да/Нет |
| Дата врем_нетрудоспособн | Дата/время | Краткий формат даты |
| Ставка | Текстовый | Мастер подстановок |
Таблица 5. Структура таблицы Вакансии
| Поле | Тип данных | Комментарий |
| Код вакансии | Счетчик | Ключ |
| Код отдела/кафедры | Числовой | Поле со списком таблица «Отделы/Кафедры» |
| Код должности | Числовой | Поле со списком таблица «Должность» |
| Кол-во вакансий | Числовой | |
| Тип вакансии | Текстовый | Мастер подстановок |
| Дата объявл_вакансии | Дата/время | Краткий формат даты |
| Дата окончан_вакансии | Дата/время | Краткий формат даты |
Таблица 6. Структура таблицы Штатное расписание
| Поле | Тип данных | Комментарий |
| Код шт_ед | Числовой | Ключ |
| Код отдела/кафедры | Числовой | Поле со списком таблица «Отделы/Кафедры» |
| Код должности | Числовой | Поле со списком таблица «Должность» |
| Кол-во шт ед | Числовой | |