Figure 6. Construction of the relational database of TissueMiner.

(A) Conceptual scheme of the database. Entities (square boxes) are related to other entities by associations (rounded boxes). Each entity contains an identifier (underlined) that uniquely defines each record. The database can be implemented by converting entities into tables (see appendix 1 and Figure 6—figure supplement 2). (B) Cell lineage trees are stored in the database: upon division a mother cell identifier a gives rise to two new daughter cell identifiers b and c. {a,b,c,d,e,f,g} defines one lineage group. (C) A pixelated cell contour in the 2D cell network: green=bond pixels, red=vertex pixels, white=other cell network pixels. (D) Vectorized representation of the cell shown in (C). To preserve the topology of the cell network, directed bonds (cyan) are defined from within a given cell alpha and ordered anticlockwisely along the cell contour. Each directed bond is complemented by a conjugated bond (magenta) and is linked to it next counter-clockwise follower (dashed).

DOI: http://dx.doi.org/10.7554/eLife.14334.027

Figure 6—figure supplement 1. Tracked cells identified by unique colors in TissueAnalyzer.

(A) shows two consecutive frames depicting colored-tracked cells from a time-lapse movie processed with TissueAnalyzer. Each cell is assigned a color identifier that uniquely defines it in the course of the time-lapse. One pixel wide cell-cell interfaces are visible in white on the raster image.

DOI: http://dx.doi.org/10.7554/eLife.14334.028

Figure 6—figure supplement 2. Logical scheme of the relational database.

(A) The conceptual scheme shown in Figure 6A can be automatically converted to a logical scheme shown here by using softwares such as IntelliJDEA or MySQL workbench. The rules of conversion are briefly evoked in appendix 1. The entities defined in the conceptual scheme are converted into tables containing one primary key (upper part of the table) that uniquely defines each record in the table, the properties of each record, and the foreign keys (arrows). Foreign keys are properties of one table pointing to the primary key of a related table (ex: conj_dbond_id:dbond_id means that the conj_dbond_id column is a foreign key whose values must be defined in the dbond_id column of the dbonds table). As a consequence of logical contraints by foreign keys, tables harbor more columns that one expected from looking at Figure 6A. This logical scheme now shows all tables and columns of the database. This scheme is implemented in physical SQLite tables can are indexed for the sake of performance (see CreateDbFromParser.R on https://github.com/mpicbg-scicomp/tissue_miner).

DOI: http://dx.doi.org/10.7554/eLife.14334.029