27006

Построение концептуальной модели данных

Лабораторная работа

Информатика, кибернетика и программирование

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

Русский

2013-08-19

111.5 KB

361 чел.

ЛАБОРАТОРНАЯ РАБОТА №8.

Построение концептуальной модели данных.

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

Краткие теоретические сведения.

1. Общие положения

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

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

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

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

Техника проектирования баз данных может измениться в целом и в деталях в зависимости от назначения системы. Например, следует различать проектирование систем складирования данных и проектирование так называемых OLTP-систем, ориентируемых на оперативную обработку транзакций. В данном учебном курсе рассматривается проектирование баз данных в основном для OLTP-систем. Именно на таких системах исторически сложилась техника проектирования баз данных.

2. Этапы проектирования базы данных

Процесс проектирования включает в себя следующие этапы:

Концептуальное проектирование – это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.

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

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

3. Концептуальное проектирование

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

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

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

  1.  Функциональный подход к проектированию БД

Этот метод реализует принцип "от задач" и применяется тогда, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

  1.  Предметный подход к проектированию БД

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

  1.  Проектирование с использованием метода "сущность-связь"

Метод "сущность–связь" (entityrelation, ERmethod) является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает её на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются.

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

Сущность – это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, СОТРУДНИК или АВТОМОБИЛЬ), так и абстрактные (например, ЭКЗАМЕН или ДИАГНОЗ).

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

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

Для каждой сущности выбираются свойства (атрибуты). Различают:

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

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

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

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

По типу различают множественные связи "один к одному" (1:1), "один ко многим" (1:N) и "многие ко многим" (M:N).

Степень связи определяется количеством сущностей, которые охвачены данной связью. Пример бинарной связи – связь между отделом и сотрудниками, которые в нём работают. Примером тернарной связи является связь типа экзамен между сущностями ДИСЦИПЛИНА, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Из последнего примера видно, что связь также может иметь атрибуты (в данном случае это Дата проведения и Оценка). Пример ER–диаграммы с указанием сущностей, их атрибутов и связей приведен на рис. 1.

Рисунок 1 - Пример ER–диаграммы с однозначными и многозначными атрибутами

4. ПРИМЕР ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

4. 1 Концептуальное проектирование

4.1.1 Анализ предметной области

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

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

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

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

Выделим базовые сущности этой предметной области:

  1.  Сотрудники компании. Атрибуты сотрудников – ФИО, табельный номер, пол, дата рождения, паспортные данные, ИНН, должность, оклад, домашний адрес и телефоны. Для редакторов необходимо хранить сведения о редактируемых книгах; для менеджеров – сведения о подписанных контрактах.
    1.  Авторы. Атрибуты авторов – ФИО, ИНН (индивидуальный номер налогоплательщика), паспортные данные, домашний адрес, телефоны. Для авторов необходимо хранить сведения о написанных книгах.
    2.  Книги. Атрибуты книги – авторы, название, тираж, дата выхода, цена одного экземпляра, общие затраты на издание, авторский гонорар.
    3.  Контракты будем рассматривать как связь между авторами, книгами и менеджерами. Атрибуты контракта – номер, дата подписания и участники.
    4.  Для отражения финансового положения компании в системе нужно учитывать заказы на книги. Для заказа необходимо хранить номер заказа, заказчика, адрес заказчика, дату поступления заказа, дату его выполнения, список заказанных книг с указанием количества экземпляров.

ER–диаграмма издательской компании приведена на рис. 2 (базовые сущности на рисунках выделены полужирным шрифтом).

Рисунок 2 - ER–диаграмма издательской компании

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

Система создаётся для обслуживания следующих групп пользователей:

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

Определим границы информационной поддержки пользователей:

1) Функциональные возможности:

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

2) Готовые запросы:

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

Задание по работе: по заданному описанию предметной области построить концептуальную модель базы данных :

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

и проанализируйте информационные задачи и группы пользователей.

Вариант1.

Задача – организация учебного процесса в вузе:

* Студенты: паспортные данные, адрес, дата зачисления, номер приказа, факультет, группа, является ли старостой, кафедра (специализация), изучаемые (изученные) предметы, оценки, задолженности, стипендия.
* Учебные курсы: название, факультет(ы), групп(ы), кафедра, семестр(ы), форма отчётности, число часов.
* Преподаватели: паспортные данные, адрес, телефон, фотография, кафедра, должность, учёная степень, начальник (зав. кафедрой), предмет(ы), число ставок, зарплата.

.

Вариант2.

Учет и выдача книг в библиотеке вуза:

* Книги: авторы, название, раздел УДК, раздел (техническая, общественно-политическая и т.п.), место и год издания, издательство, количество страниц, иллюстрированность, цена, дата покупки, номер сопроводительного документа (чек, счёт/накладная), вид издания (книги, учебники, брошюры, периодические издания), инвентарный номер (есть только для книг и некоторых учебников), длительность использования читателями (год, две недели, день), электронная версия книги или ее реферата (отсканированный текст).
* Читатели: номер читательского билета, ФИО, год рождения, адрес, дата записи, вид (студент, аспирант, преподаватель, сотрудник), курс, номер группы, названия взятых книг и даты их выдачи.

Вариант3.

Отдел кадров некоторой компании.
* Сотрудники: ФИО, паспортные данные, фотография, дом. и моб. телефоны, отдел, комната, раб. телефоны (в т.ч. местный), подчинённые сотрудники, должность, тип(ы) работы, задание(я), проект(ы), размер зарплаты, форма зарплаты (почасовая, фиксированная).
* Отделы: название, комната, телефон(ы), начальник, размер финансирования, число сотрудников.
* Проекты: название, дата начала, дата окончания, размер финансирования, тип финансирования (периодический, разовый), задачи и их исполнители, структура затрат и статьи расходов.

Вариант4.

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

Вариант5.

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

Вариант6.

Пункт проката видеозаписей (информация для клиентов).
* Видеокассеты: краткое описание, внешний вид (этикетка), марка (пустой) видеокассеты, цена за единицу прокатного времени (например: 1 день, 3 дня, неделя), есть ли в наличии, общая длительность записей; записи на видеокассете: название, длительность, жанр (категория), тема, год и страна выпуска (оригинала), кинокомпания, описание, актеры, режиссер.
* Заказы: идентификационные номера и названия выданных видеокассет, дата выдачи, дата возвращения (продления), общая стоимость заказа, возвращены ли кассеты заказа.

Вариант7.

Кинотеатры (информация для зрителей).
* Фильмы: название, описание, жанр (категория), длительность, популярность (рейтинг, число проданных билетов в России и в мире), показывается ли сейчас (сегодня, на текущей неделе), в каких кинотеатрах показывается, цены на билеты (в т.ч. средние).
* Кинотеатры: название, адрес, схема проезда, описание, число мест (в разных залах, если их несколько), акустическая система, широкоэкранность, фильмы и цены на них: детские и взрослые билеты в зависимости от сеанса (дневной, вечерний и т.п.) и от категории мест (передние, задние и т.п.); сеансы показа фильмов (дата и время начала).

Вариант8.

Ресторан (информация для посетителей).
* Меню: дневное или вечернее, список блюд по категориям.
* Блюда: цена, название, вид кухни, категории (первое, второе и т.п.; мясное, рыбное, салат и т.п.), является ли вегетарианским, компоненты блюда, время приготовления, есть ли в наличии.
* Компоненты блюд: тип (гарнир, соус, мясо и т.п.), калорийность, цена, рецепт, время приготовления, есть ли в наличии, ингредиенты (продукты) и их расходы на порцию.

Вариант9.

Задача- информационная поддержка деятельности склада.

База данных должна содержать информацию о наименовании товара, его поставщике, количестве, цене товара, конечном сроке реализации, сроке хранения на складе. Торговый  склад производит уценку хранящейся продукции. Если продукция хранится на складе дольше 10 месяцев, то она уценивается в 2 раза, а если срок хранения превысил 6 месяцев, но не достиг 10, то в 1,5 раза. Ведомость уценки товаров должна содержать информацию: наименование товара, количество товара(шт.), цена товара до уценки, срок хранения товара, цена товара после уценки, общая стоимость товаров после уценки.

Вариант10.

Задача – информационная поддержка деятельности адвокатской конторы. БД должна осуществлять:

ведение списка адвокатов;

ведение списка клиентов;

ведение архива законченных дел.

Необходимо предусмотреть:

получение списка текущих клиентов для конкретного адвоката;

определение эффективности защиты (максимальный срок минус полученный срок) с учётом оправданий, условных сроков и штрафов;

определение неэффективности защиты (полученный срок минус минимальный срок);

подсчёт суммы гонораров (по отдельных делам) в текущем году;

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

Вариант11.

Задача – информационная поддержка деятельности гостиницы.

БД должна осуществлять:

ведение списка постояльцев;

учёт забронированных мест;

ведение архива выбывших постояльцев за последний год.

Необходимо предусмотреть:

получение списка свободных номеров (по количеству мест и классу);

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

выдачу информации по конкретному номеру;

автоматизацию выдачи счетов на оплату номера и услуг;

получение списка забронированных номеров;

проверку наличия брони по имени клиента и/или названию организации

Вариант12.

Описание предметной области:

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

В базе данных должна храниться следующая информация.

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

Вариант13.

Задача – информационная поддержка деятельности спортивного клуба. БД должна осуществлять:

ведение списков спортсменов и тренеров;

учёт проводимых соревнований (с ведением их архива);

учёт травм, полученных спортсменами.

Необходимо предусмотреть:

возможность перехода спортсмена от одного тренера к другому;

составление рейтингов спортсменов;

составление рейтингов тренеров;

выдачу информации по соревнованиям;

выдачу информации по конкретному спортсмену;

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

Вариант14.

Задача – информационная поддержка деятельности аптечного склада.

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

Вариант15.

“Электронный журнал посещаемости"

Предметная область представлена следующими документами:

Список студентов

Журнал посещаемости

Расписание занятий

Предусмотреть учет пропусков по уважительным, неуважительным причинам. Подсчет

пропусков по каждому студенту, за неделю, месяц, заданный период, по конкретному

предмету.

Вариант16.

«Итоги сессии» 

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

Контрольные вопросы.

  1.  Назовите основные этапы проектирования базы данных.
  2.  Какова основная цель этапа концептуального проектирования.
  3.  Объясните смысл понятия «представление пользователя » и укажите источники информации, которые могут использоваться при создании этого представления.


 

А также другие работы, которые могут Вас заинтересовать

24618. Облік доходів та витрат майбутніх періодів 28.5 KB
  Облік доходів та витрат майбутніх періодів Облік доходів майбутніх періодів Для узагальнення інформації щодо одержаних доходів у звітному періоді які підлягають включенню до доходів у майбутніх періодах призначено рахунок 69. періодів відносять доходи у вигляді одержаних авансових платежів за здані в оренду о. періодів за Дт їх списання на рахунок обліку доходів та включення до складу доходів звітного періоду. періодів Дт301311373670 Кт69 2списано доходи майб.
24619. Облік розрахунків з постачальниками та іншими кредиторами 28.5 KB
  Облік розрахунків з постачальниками та іншими кредиторами Облік розрах. Для обліку таких операцій використовують рахунок 68 Розрахунки за іншими операціями на якому обліковують розрахунки за операціями що не можна відобразити на рахунках 63 67.За кредитом рахунку 68 показують збільшення заборгованості перед іншими кредиторами за дебетом її погашення списання. 685 Розрахунки з іншими кредиторами.
24620. Облік розрахунків за податками і платежами 31.5 KB
  за податками податок на прибуток ПДВ акцизний збір 642 розрах. за обовязковими платежами місцеві податки транспортний податок 643 податкові зобовязання облік суми ПДВ на яку збільш. податковий кредит 644 податковий кредит облік ПДВ на яку підпрво має право зменшити податкове зобовязання. бюджету перед платником Дт311 Кт641 Кредитове сальдо Дт 641 Кт 311 Законодавче регулювання: ЗУ Про ПДВ ЗУ Про акцизний збір на алкогольні напої та тютюнові вироби ЗУ про оподатковув.
24621. Предмет і Метод бухгалтерського обліку 27.5 KB
  Предмет і Метод бухгалтерського обліку Предметом бух обліку є господарські факти явища і процеси операції що зумовлюють рух господарських засобів коштів та джерел їх утворення. Предмет бух обліку охоплює процес виробництва розподілу обігу та споживання.обліку це сукупність прийомів і способів за допомогою яких господарська діяльність підприємства відображається в обліку.
24622. Правове регулювання біх. обліку та фінансової звітності в Україні 26 KB
  обліку та фінансової звітності в Україні Основні нормативні акти які регулюють побудову та організацію на підприємстві. Організація бух обліку на підприємстві регулюється законом україни про бух облік та фін звітність.При організації і ведені б о підприємства керуються положеннями б о які являють собою нормативно правові акти затверджені мін фіном україни що визначають принципи та методи ведення б о і складання фін звітності що не суперечать міжнародним стандартам.Наказом мін фін україни було затверджено план рахунків б о активів капіталу...
24623. Облікова політика підприємства, її суть і значення 27 KB
  У відповідності з законом україни про б о та фін звітність в україні облікова політика це сукупність принципів методів і процедур що використовуються підприємством для складання та подання фін звітності. Фін результати залежать від способів обліку: 1.оцінки елементів затрат виробництва та їх групування і т д Облікова політика може змінюватися у випадках коли змінюються статутні вимоги і якщо зміни забезпечать реальне відображення операцій у фін звітності підприємства.Обл політика та її зміни відображаються у підтримках до фін звітності.
24624. Рахунки синтетичного і аналітичного обліку, їх взаємозв’язок 25 KB
  Рахунки синтетичного і аналітичного обліку їх взаємозвязок. По обєму записів рахунки бувають синтетичними і аналітичними. Всі рахунки балансу є синтетичними. Але в багатьох випадках для цілей управління і контролю такої інформації не достатньо тому синтетичні рахунки можуть поділитися на більш детальні аналітичні рахунки.
24626. Бухгалтерський баланс та його структура 40 KB
  Існує два визначення балансу: економічне згідно з яким це спосіб економічного групування та узагальненого відображення у грошовій оцінці стану господарських засобів і джерел їх утворення на певну дату і бухгалтерське згідно з яким це двобічна таблиця ліва частина якої актив призначена для відображення засобів підприємства права пасив для відображення джерел їх формування. Зміст форма балансу та загальні вимоги до розкриття його статей визначаються Положенням стандартом бухгалтерського обліку 2 затвердженим наказом Міністерства...